[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs
From: |
Richard W.M. Jones |
Subject: |
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs |
Date: |
Mon, 9 Jul 2018 10:11:16 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs, Laszlo Ersek, 2018/07/05
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs, Daniel P . Berrangé, 2018/07/05
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs, Laszlo Ersek, 2018/07/05
Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs, Michael S. Tsirkin, 2018/07/05