Re: [RESEND PATCH v2 2/3] hvmloader: Update to SMBIOS 2.6

["Anthony PERARD" <anthony.perard@xxxxxxxxxx>]

On Fri, Aug 29, 2025 at 09:58:16AM +0000, Teddy Astie wrote:
> Currently, hvmloader uses SMBIOS 2.4, however, when using OVMF, the
> SMBIOS is patched to 2.8, which has clarified the UUID format (as GUID).
> 
> In Linux, if the SMBIOS version is >= 2.6, the GUID format is used, else
> (undefined as per SMBIOS spec), big endian is used (used by Xen). Therefore,
> you have a endian mismatch causing the UUIDs to mismatch in the guest.
> 
> $ cat /sys/hypervisor/uuid
> e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7
> $ cat /sys/devices/virtual/dmi/id/product_uuid
> 3fe665e8-303d-0b4f-83e0-8fdfc1e30eb7
> $ cat /sys/devices/virtual/dmi/id/product_serial
> e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7
> 
> This patch updates the SMBIOS version from 2.4 to 2.6 and does the appropriate
> modifications of the table. This effectively fix this endianness mismatch with
> OVMF; while the UUID displayed by Linux is still the same for SeaBIOS.

Just curious, why change hvmloader to generate an SMBIOS v2.6 table
when OVMF later say it's v2.8 ? Why do we change hvmloader when the
problem is OVMF making change to the table before giving it to the OS?

As far as I can tell, OVMF doesn't take into account the version of the
SMBIOS table provided by hvmloader and just use the default set at build
time. This can be changed with the PCD
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion, it's currently set to
v2.8. The main used of the version number by OVMF seems to be to check
the max sizes.

Before making any changes in hvmloader, we should first fix OvmfXen to
take into account the version of the SMBIOS table that is received.
Otherwise, we just add more tech dept. We might one day want to use a
newer version of SMBIOS, OVMF should be ready by then.


Now, for the change of SMBIOS version. I think that starting to provide
a v2.6 is a good move, but we should list the correct reason for doing
so. OVMF can mostly stay out of the picture here, and be fix separately.
One main issue we can state is that Linux and Windows interpret the UUID
in the SMBIOS differently, when the version is v2.4. I've booted Windows
with SeaBIOS and read the UUID from the SMBIOS table with

    wmic csproduct get uuid

and the UUID return is read according to the new definition propose in
SMBIOS v2.6, even if the table is said to be v2.4, so the UUID is
different from the one set by the toolstack. Moving to v2.6 would indeed
fix this discrepancy.


Next, we are going to want a way to fallback to v2.4 when a guest needs
to observe no changes across reboot. `xl` already have
`smbios_firmware=` which is passthrough `hvmloader` via xenstore entry
`hvmloader/smbios/{address,length}`, but that interface would allow to
only replace a structure (like replacing the type 1 structure) and
doesn't allow to change the version. (And that would duplicate SMBIOS
table generation between hvmloader and the toolstack, which isn't ideal.)
So, will need some changes to `xl`, `libxl`, and `hvmloader`.


> Fixes: c683914ef913 ("Add code to generate SMBIOS tables to hvmloader.")
> (SMBIOS versions before 2.6 has a ill-defined UUID definition)

This space in a commit description is usually reserved for tags and
sometime comment of change made to a patch while
committing/cherry-picking. Comment about a previous commit can be before
these tags, like stating that "commit a1b2c3 made some unhelpful
changes and still have the Fixes:a1b2c3 (...) tag.

> Signed-off-by: Teddy Astie <teddy.astie@xxxxxxxxxx>

Thanks,

-- 

--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech