Hi,
The UUID seabios reports in its boot output doesn't match what is passed via qemu -uuid option. An example is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1284259
This is due to:
commit caad057bb6ce86a9cb71520af395fd0bd04a659f Author: Eduardo Habkost ehabkost@redhat.com Date: Wed Oct 29 11:26:08 2014 -0200
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5.
seabios doesn't seem to handle this special UUID format when reading from smbios.
Thanks, Cole
On Di, 2015-11-24 at 11:55 -0500, Cole Robinson wrote:
Hi,
The UUID seabios reports in its boot output doesn't match what is passed via qemu -uuid option. An example is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1284259
This is due to:
commit caad057bb6ce86a9cb71520af395fd0bd04a659f Author: Eduardo Habkost ehabkost@redhat.com Date: Wed Oct 29 11:26:08 2014 -0200
smbios: Encode UUID according to SMBIOS specification Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields: > Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5.seabios doesn't seem to handle this special UUID format when reading from smbios.
Hmm. Changing the ordering in display_uuid() is easy. There seems to be no easy way to figure which format to use though. Checking the version like dmidecode doesn't fly as there are qemu versions with old format but version smbios 2.8 in the wild ...
cheers, Gerd
On 11/26/15 08:43, Gerd Hoffmann wrote:
On Di, 2015-11-24 at 11:55 -0500, Cole Robinson wrote:
Hi,
The UUID seabios reports in its boot output doesn't match what is passed via qemu -uuid option. An example is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1284259
This is due to:
commit caad057bb6ce86a9cb71520af395fd0bd04a659f Author: Eduardo Habkost ehabkost@redhat.com Date: Wed Oct 29 11:26:08 2014 -0200
smbios: Encode UUID according to SMBIOS specification Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields: > Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5.seabios doesn't seem to handle this special UUID format when reading from smbios.
Hmm. Changing the ordering in display_uuid() is easy. There seems to be no easy way to figure which format to use though. Checking the version like dmidecode doesn't fly as there are qemu versions with old format but version smbios 2.8 in the wild ...
Plus, because this is guest visible, Eduardo's patch noted above only changes the encoding for 2.2 and later QEMU machine types. If you run your reproducer but flip the machine type to 2.1 or earlier, you should see the UUID on the SeaBIOS screen change.
Thanks Laszlo
On Thu, Nov 26, 2015 at 07:40:10PM +0100, Laszlo Ersek wrote:
On 11/26/15 08:43, Gerd Hoffmann wrote:
On Di, 2015-11-24 at 11:55 -0500, Cole Robinson wrote:
Hi,
The UUID seabios reports in its boot output doesn't match what is passed via qemu -uuid option. An example is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1284259
This is due to:
commit caad057bb6ce86a9cb71520af395fd0bd04a659f Author: Eduardo Habkost ehabkost@redhat.com Date: Wed Oct 29 11:26:08 2014 -0200
smbios: Encode UUID according to SMBIOS specification Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields: > Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5.seabios doesn't seem to handle this special UUID format when reading from smbios.
Hmm. Changing the ordering in display_uuid() is easy. There seems to be no easy way to figure which format to use though. Checking the version like dmidecode doesn't fly as there are qemu versions with old format but version smbios 2.8 in the wild ...
QEMU versions with the old format but smbios 2.8 are buggy, and exposing a broken UUID to guests. I don't believe you need to work around that QEMU bug in the tools that display the UUID.
That translates to: * pc-2.2 and later report SMBIOS 2.8 and use the correct format, so it's OK * pc-2.1 is buggy, because it reports SMBIOS 2.8 and use the old format * pc-2.0 and older is OK, because it lets SeaBIOS build the SMBIOS tables, which uses the old format and reports SMBIOS 2.4
Showing the wrong UUID when using pc-2.1 seems unavoidable (because that's a QEMU Bug). But you should be able to display the right UUID on all other pc versions (pc <= 2.0 or pc >= 2.2).
Plus, because this is guest visible, Eduardo's patch noted above only changes the encoding for 2.2 and later QEMU machine types. If you run your reproducer but flip the machine type to 2.1 or earlier, you should see the UUID on the SeaBIOS screen change.
Not 2.1 or earlier, but 2.1 only. If you use 2.0 or earlier, the UUID should be correct.
-
Cole Robinson -
Eduardo Habkost -
Gerd Hoffmann -
Laszlo Ersek