diff options
author | Eduardo Habkost <ehabkost@redhat.com> | 2014-10-29 11:26:08 -0200 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2014-11-02 13:44:52 +0200 |
commit | caad057bb6ce86a9cb71520af395fd0bd04a659f (patch) | |
tree | 9b26db555e09f85d22fd934e334769d124fb2997 /vl.c | |
parent | 2cad57c7177766e2779f30fed9e4578bc7ad62ac (diff) |
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.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'vl.c')
-rw-r--r-- | vl.c | 3 |
1 files changed, 3 insertions, 0 deletions
@@ -190,6 +190,9 @@ int nb_numa_nodes; int max_numa_nodeid; NodeInfo numa_info[MAX_NODES]; +/* The bytes in qemu_uuid[] are in the order specified by RFC4122, _not_ in the + * little-endian "wire format" described in the SMBIOS 2.6 specification. + */ uint8_t qemu_uuid[16]; bool qemu_uuid_set; |