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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Hello,

Le 17/12/2025 à 16:26, Anthony PERARD a écrit :
> 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.
>

That would be better, but with a small issue. SMBIOS 2.4 doesn't define
EFI as a way to query SMBIOS location. That probably doesn't really
matter, as the table content of 2.4 still has a meaning in the next
SMBIOS specifications; but is still worth noting.

>
> 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.
>
On Windows, only doing the endianness change (expected for v2.6) would
fix what Windows reads, as AFAIU it always considers GUID encoding.

>
> 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`.
>

I had in mind the idea of moving the entire SMBIOS table creation to be
fully done in the toolstack (to give it full control on this); so
hvmloader will no longer have to generate it. The caveats is that it
implies moving various things around.

>
>> 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,
>

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech