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
