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
