On 28.08.2025 12:01, Andrew Cooper wrote:
> On 28/08/2025 8:07 am, Jan Beulich wrote:
>> On 27.08.2025 19:47, Andrew Cooper wrote:
>>> On 22/08/2025 2:47 pm, 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 fixup the UUID
>>>> written in the table; which effectively fix this endianness mismatch with
>>>> OVMF; while the UUID displayed by Linux is still the same for SeaBIOS.
>>>>
>>>> Signed-off-by: Teddy Astie <teddy.as...@vates.tech>
>>>> ---
>>>> This effectively changes the UUID seen with UEFI guests as it was
>>>> actually inconsistent with SeaBIOS and SMBIOS expectations.
>>>> ---
>>> I agree this is a real bug and needs fixing.
>> Hmm, I didn't realize this is a bug, and hence put the patch off as 4.22
>> material. If there is a bug being fixed: Teddy, please add a Fixes: tag.
> 
> I'm not sure if this has a reasonable Fixes tag.
> 
> It's a combination of an ill-specified domain handle format, and using
> an ill-specified version of the SMBios spec.

But the problem was still introduced into the code base at some point. Afaict
in c683914ef913 ("Add code to generate SMBIOS tables to hvmloader"), i.e. when
smbios.c was first added.

Jan

Reply via email to