[Fw_Os_Forum] [PI 1.10] Specification change for >64KB HOB support

[Armin Wolf]

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