Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs

[Richard W.M. Jones]

On Mon, Jul 09, 2018 at 11:05:34AM +0200, Laszlo Ersek wrote:
> On 07/09/18 09:36, Richard W.M. Jones wrote:
> > On Thu, Jul 05, 2018 at 03:11:32PM +0100, Richard W.M. Jones wrote:
> >> VMware represents these internally as two signed 64 bit integers, eg:
> >>
> >>   vm.genid = "-570734802784577186"
> >>   vm.genidx = "-5042519231342505152"
> >>
> >> I am still trying to get verification, but I believe the first is the
> >> low 64 bit word and the second is the high 64 bit word.
> > 
> > I have now been able to verify how this works using a real VMware
> > hypervisor (thanks to help from Ming Xie).  For the record, here is
> > how it maps, since I could not find any documentation about this.
> > 
> > VMX file contains:
> > 
> >   vm.genid = "7344585841658099715"
> >   vm.genidX = "-8483171368186442967"
> > 
> > Those numbers are signed 64 bit integers written in hex as:
> > 
> >   vm.genid = 65 ED 35 E8 E2 64 F8 03
> >   vm.genidX = 8A 45 B8 96 1E 7B 8B 29
> 
> If you mean to describe the byte array representations: these are the
> big endian ones.

Yes, the spaces were not meant to indicate that this is the in-memory
representation.

> > In the guest the VMGENID.EXE program prints (with my spaces added for
> > clarity):
> 
> Right, it's important to note that the spaces below were added for
> clarity. The decimal constant 7344585841658099715 is equal to the
> hexadecimal constant 0x65ED35E8E264F803. The big endian byte array
> representation for that is what you quote above, the little endian one
> is the reverse.
> 
> >   VmCounterValue: 65 ED 35 E8 E2 64 F8 03 : 8A 45 B8 96 1E 7B 8B 29
> > 
> > So this confirms my original guess.  Note that VMware is not doing any
> > endianness adjustment, but then VMware only works on LE hardware.
> 
> Thanks for tracking this down -- TIL.
> 
> (My above remarks are not meant as disagreement: it looks like VMWare
> simply stores the int64_t values from the config file to guest memory,
> without any kind of conversion. I only meant to comment on your
> paragraph "written in hex as ...", because it wasn't clear to me whether
> you meant "as uint64_t with spaces for clarity" or "as uint8_t[8]". The
> latter is endianness-dependent, and the rendering you gave was BE, which
> seemed to conflict with your final statement.)

Agreed too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html