Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs

[Laszlo Ersek <lersek@redhat.com>]

Hi Rich,

On 07/05/18 14:52, Richard W.M. Jones wrote:
> On Thu, Jul 05, 2018 at 01:39:29PM +0100, Richard W.M. Jones wrote:
>> I was doing a bit of investigation around how different hypervisors
>> handle the VM Generation ID feature.  QEMU's behaviour seems quite
>> strange, I wonder if this is a bug or expected?
>>
>> (1) I booted a Windows 2016 VM with:
>>
>>   qemu-system-x86_64 -M pc,accel=kvm -m 2G -hda w2k16-mincore.img \
>>       -device vmgenid,guid=01020304-0506-0708-090a-0b0c0d0e0f00,id=vmgenid0
>>
>> (2) Inside the guest I used the VMGENID.EXE program from:
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1598350#c3
>>   https://docs.microsoft.com/en-gb/windows/desktop/HyperV_v2/virtual-machine-generation-identifier
>>
>> Note this is self-compiled using mingw64-g++ (not using Visual Studio
>> which I don't have available), but I don't believe that could have
>> caused the problem.
>>
>> (3) The program prints:
>>
>>   VmCounterValue: 708050601020304:f0e0d0c0b0a09
>>
>> To make it easier to see, this is the same number but zero-extended:
>>
>>   VmCounterValue: 07 08 05 06 01 02 03 04 : 00 0f 0e 0d 0c 0b 0a 09
>>                   \________ LOW ________/   \_______ HIGH _______/
>>                             WORD                     WORD
>>
>> As you can see it looks like there is no clear relationship between
>> the order of the bytes in the guid= parameter and the order that they
>> are seen by Windows.
>
> OK after examining util/uuid.c and the qemu_uuid_bswap function,
> I sort of see what's going on here.
>
> FWIW other hypervisors seem to store these as two 64 bit integers.

This is a bit tricky. Please refer to the following:

* https://bugzilla.redhat.com/show_bug.cgi?id=1118834#c21
* http://mid.mail-archive.com/c052d05e-71a5-1a6a-f34f-17d14167c2f6@redhat.com

in particular steps (8) + (9), and (15) + (16).

The QEMU device model takes the UUID (GUID) in textual representation
and stores it in guest memory in little endian binary UUID
representation. Historically, components of the UUID used to be encoded
in big endian, when represented in binary; however, as e.g. the SMBIOS
spec states (in "7.2.1 System -- UUID"), Microsoft uses little endian
encoding, for representing those fields of the UUID, in binary, that are
not simple byte arrays. (This has BTW leaked into other domains, for
example ACPI and UEFI).

In turn, the test program that you used didn't print the binary value in
either UUID format or raw byte dump format -- instead, it interpreted
the first 8 bytes as a little-endian uint64_t, and the second 8 bytes as
another uint64_t.

Applied to your example, we have:

  01020304-0506-0708-090a-0b0c0d0e0f00

  time_low:                  0x01020304 (DWORD)
  time_mid:                  0x0506 (WORD)
  time_hi_and_version:       0x0708 (WORD)
  clock_seq_hi_and_reserved: 0x09 (BYTE)
  clock_seq_low:             0x0a (BYTE)
  Node:                      0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00 (BYTE[6])

The DWORD and WORD fields are sensitive to endianness. When using
little-endian, the full raw representation, and the uint64_t
interpretations will be:

  time_low                time_mid    time_hi_and_version  clock_seq_hi_and_reserved  clock_seq_low         Node
  ----------------------  ----------  -------------------  -------------------------  --------------------  ----------------------------------
  0x04, 0x03, 0x02, 0x01, 0x06, 0x05, 0x08, 0x07,          0x09,                      0x0a,                 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00
  -------------------------------------------------------  -----------------------------------------------------------------------------------
  uint64_t: 0x0708050601020304                             uint64_t: 0x000f0e0d0c0b0a09

QEMU does the right thing. If other hypervisors don't do this -- while
still taking and displaying the value in UUID / GUID textual format --,
they are wrong. The VMGENID spec from Microsoft
<http://go.microsoft.com/fwlink/?LinkId=260709> specifically mentions
"GUID".

Thanks,
Laszlo