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

[Laszlo Ersek <lersek@redhat.com>]

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.

> 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.)

Thanks!
Laszlo