Re: [PATCH 0/1] vmx: Fix <genid/> mapping

[Laszlo Ersek]

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-across-hypervisors.txt

> 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