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
