From daniel at quora.org  Thu Feb 12 05:17:51 2026
From: daniel at quora.org (Daniel J Blueman)
Date: Thu, 12 Feb 2026 18:17:51 +0800
Subject: [Fw_Os_Forum] [PI 1.10] Specification change for >64KB HOB support
Message-ID: <CAMVG2sv+2abm47XpGiJmS4+cnnWdbFa-CWYbaamjuhDFw2DxWg@mail.gmail.com>

Technology partners I work with routinely run into the 16-bit HOB
length limit [1], employing a variety of workarounds including
transferring pointers or splitting content among HOBs, breaking the
spec in an implementation-defined way thus losing interop.

I propose this is fixed by introducing HOB version 11, reusing part of
the reserved field for upper 16 bits of length, going from:

#define EFI_HOB_HANDOFF_TABLE_VERSION   0x000a

typedef struct _EFI_HOB_GENERIC_HEADER {
  UINT16  HobType;
  UINT16  HobLength;
  UINT32  Reserved; // PI1.9: "must always be set to zero"
} EFI_HOB_GENERIC_HEADER;

to:

#define EFI_HOB_HANDOFF_TABLE_VERSION   0x000b

typedef struct _EFI_HOB_GENERIC_HEADER {
  UINT16  HobType;
  UINT16  HobLength;
  UINT16 HobLengthHigh;
  UINT16 Reserved; // PI1.10: "must always be set to zero"
} EFI_HOB_GENERIC_HEADER;

Newer implementations (PI 1.10 or later) will thus interpret older
HOBs correctly to maintain backwards ABI compatibility since the
reserved bits in compliant implementations are guaranteed to be zero.

Conversely, newer implementations emitting HOBs smaller than 64KB will
be ABI compatible with PI 1.9 consumers, however where producers and
consumers are PI 1.10 or later, there is freedom to (finally) use HOBs
larger than 64KB.

Objections to this crucial change and standardisation?

Thanks,
  Daniel

-- [1] https://uefi.org/specs/PI/1.9/V3_HOB_Code_Definitions.html
-- 
Daniel J Blueman