On 10/04/21 11:59, Richard W.M. Jones wrote:
It turns out that changing the qemu implementation is painful,
particularly if we wish to maintain backwards compatibility of the
command line and live migration.
Instead I opted to document comprehensively what all the
different hypervisors do:
https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-...
Unfortunately QEMU made a significant mistake when implementing this
feature. Because the string is 128 bits wrong, they decided it must
^^^^^^^^^^^^^^
Haha, that's a great typo :)
be a UUID (as you can see above there is no evidence that Microsoft
who wrote the original spec thought it was). Following from this
incorrect assumption, they stated that the "UUID" must be supplied to
qemu in big endian format and must be byteswapped when writing it to
guest memory. Their documentation says that they only do this for
little endian guests, but this is not true of their implementation
which byte swaps it for all guests.
I don't think this is what section "Endian-ness Considerations" in
"docs/specs/vmgenid.txt" says. That text says that the *device* uses
little-endian format. That's independent of the endianness of *CPU* of
the particular guest architecture.
So the byte-swapping in the QEMU code occurs unconditionally because
QEMU's UUID type is inherently big endian, and the device model in
question is fixed little endian. The guest CPU's endianness is
irrelevant as far as the device is concerned.
If a BE guest CPU intends to read the generation ID and to interpret it
as a set of integers, then the guest CPU is supposed to byte-swap the
appropriate fields itself.
References
I suggest adding two links in this section, namely to:
- docs/specs/vmgenid.txt
- hw/acpi/vmgenid.c
Thanks,
Laszlo