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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 29, 2021 at 10:57:19AM +0100, Richard W.M. Jones wrote:
> Looking at the qemu code the problem IMHO is:
> 
> https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b1930ae6c74dea/docs/specs/vmgenid.txt#L189
> https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b1930ae6c74dea/hw/acpi/vmgenid.c#L37
> 
> This byte swapping makes no sense to me.  How do we know that the
> guest is little endian?  What will this code do for BE guests?  I
> think qemu would be better off treating the "GUID" as a list of bytes
> and writing that exactly into the guest memory.

This is an artifact of the HyperV only caring about x86 and thus leaving
endianness unspecified in the spec for GenID. QEMU docs say


Endian-ness Considerations:
---------------------------

Although not specified in Microsoft's document, it is assumed that the
device is expected to use little-endian format.

All GUID passed in via command line or monitor are treated as big-endian.
GUID values displayed via monitor are shown in big-endian format.


So by extension if libvirt is passing the value from its XML straight
to QEMU, then libvirt has effectively defined that the XML is storing
it big-endian too.

This could be where the confusion with VMX config is coming into play,
though the byte re-ordering in v2v seems more complex than just an
endianess-fiddle ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|