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

More data: I found a colleague who has a Hyper-V instance with a Windows guest and he helped me to understand how Hyper-V represents generation IDs. Hyper-V has had support for generation IDs since long before Microsoft proposed the feature for standardization. Originally (I think pre-2013) Hyper-V used an XML description which included: <generation_id type="string">4a07df4361fdf4c883f97bc30e524b9d</generation_id> Note this is a pure hex string, not a GUID. In current Hyper-V, the same representation is used but it's embedded in a binary file. My colleague ran two Windows VMs on Hyper-V and examined the generation_id on the hypervisor and compared it to the output of VMGENID.EXE inside the guest. The first guest had this in the binary hypervisor metadata: 000056b0 00 00 0e 67 65 6e 65 72 61 74 69 6f 6e 5f 69 64 |...generation_id| 000056c0 00 40 00 00 00 38 00 30 00 35 00 61 00 32 00 38 |.@...8.0.5.a.2.8| 000056d0 00 37 00 61 00 32 00 35 00 30 00 39 00 38 00 39 |.7.a.2.5.0.9.8.9| 000056e0 00 65 00 34 00 66 00 65 00 36 00 66 00 36 00 39 |.e.4.f.e.6.f.6.9| 000056f0 00 39 00 32 00 62 00 65 00 33 00 33 00 34 00 61 |.9.2.b.e.3.3.4.a| 00005700 00 34 00 33 00 00 00 00 00 00 00 00 00 00 00 00 |.4.3............| and reported the output of VMGENID in this guest as: VmCounterValue: fe6f6992be334a43:805a287a250989e4 The second guest had: 00005360 c5 06 00 00 00 0e 67 65 6e 65 72 61 74 69 6f 6e |......generation| 00005370 5f 69 64 00 40 00 00 00 65 00 62 00 66 00 62 00 |_id.@...e.b.f.b.| 00005380 62 00 37 00 39 00 37 00 33 00 36 00 35 00 37 00 |b.7.9.7.3.6.5.7.| 00005390 32 00 38 00 65 00 37 00 30 00 62 00 33 00 66 00 |2.8.e.7.0.b.3.f.| 000053a0 64 00 33 00 63 00 37 00 31 00 33 00 65 00 63 00 |d.3.c.7.1.3.e.c.| 000053b0 65 00 38 00 34 00 32 00 00 00 00 00 00 00 00 00 |e.8.4.2.........| and VMGENID was: VmCounterValue: b3fd3c713ece842:ebfbb797365728e7 Note: - In both cases, the generation ID is clearly not a GUID. - The two 64 bit words are swapped over somewhere, but individual bytes are not byte-swapped, and there is again no evidence of UUID-aware byte swapping. ---------------------------------------------------------------------- So how do we get from where we are to a more sane vmgenid in qemu? I propose we deprecate the guid parameter in: -device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0 Instead it will be replaced by bytes= which will simply write the bytes, in the order they appear, into guest memory with no attempt to interpret or byte-swap. Something like: -device vmgenid,bytes=112233445566778899aabbccddeeff00,id=vmgenid0 (guid although deprecated will need to be kept around for a while, along with its weird byte-swapping behaviour). We will then have a plain and simple method to emulate the behaviour of other hypervisors. We will look at exactly what bytes they write to guest memory and copy that behaviour when v2v converting from those hypervisors.

From the libvirt POV, I'm not expecting anything in QEMU to change