On Tue, 25 Feb 2025 12:00:12 +0100 Gerd Hoffman <kra...@redhat.com> wrote:
> Hi, > > > > See > > > https://lore.kernel.org/qemu-devel/20250219071431.50626-2-kra...@redhat.com/ > > > > > > > After looking at it, it seems to me that data will be in host byte order > > and guest has no idea what that is. > > Probably it should advertise byteorder as part of the structure, > > and guest side should then do conversion if necessary. > > The structure is already defined and in use by edk2, so changing it is > not an option. Guest is little endian (there is no big endian UEFI). > So simply declaring the struct fields being little endian byte order > and convert them if needed on the host side makes alot more sense here. > I'll fix the patch accordingly for v5. given it's memcpy of blob it would be hard to do so in hardware_info_register(), doing it in caller is error prone/constant source of bugs (that was the case for ACPI tables until endianness conversion was hidden behind API). But if it's small number of places perhaps it's ok to do conversion in the caller. or alternatively instead of structure, build data as a table, similar to aml_append(aml_int()) in ACPI, which will take care of conversion. Ugly? yes, but it takes care of endianness bugs, as practice showed up. PS: if there is a doc for etc/hardware-info, then describe it there as little-endian (so reader doesn't have to deduce byte-order, it's ABI after all) > > take care, > Gerd >
