From W_Armin at gmx.de Thu Feb 19 17:01:43 2026 From: W_Armin at gmx.de (Armin Wolf) Date: Thu, 19 Feb 2026 23:01:43 +0100 Subject: [Fw_Os_Forum] [PI 1.10] Specification change for >64KB HOB support In-Reply-To: References: Message-ID: Am 12.02.26 um 11:17 schrieb Daniel J Blueman: > 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. The proposal sound good to me, would it make sense to simply extend HobLength to 32 bit (aka UINT32 HobLength) and add a comment explaining that older implementations only use the first 16 bits? Thanks, Armin Wolf > Objections to this crucial change and standardisation? > > Thanks, > Daniel > > -- [1] https://uefi.org/specs/PI/1.9/V3_HOB_Code_Definitions.html