All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	libvir-list@redhat.com, "Michal Privoznik" <mprivozn@redhat.com>,
	qemu-devel@nongnu.org, armbru@redhat.com, acatan@amazon.com
Subject: Re: [PATCH 0/1] vmx: Fix <genid/> mapping
Date: Mon, 4 Oct 2021 15:59:09 +0100	[thread overview]
Message-ID: <20211004145909.GZ3361@redhat.com> (raw)
In-Reply-To: <ecfdc6cc-c411-851f-afb6-ac301d722d99@redhat.com>

On Mon, Oct 04, 2021 at 04:50:51PM +0200, Laszlo Ersek wrote:
> On 10/04/21 11:59, Richard W.M. Jones wrote:
> > It turns out that changing the qemu implementation is painful,
> > particularly if we wish to maintain backwards compatibility of the
> > command line and live migration.
> >
> > Instead I opted to document comprehensively what all the
> > different hypervisors do:
> >
> >   https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt
> 
> > Unfortunately QEMU made a significant mistake when implementing this
> > feature.  Because the string is 128 bits wrong, they decided it must
>                                   ^^^^^^^^^^^^^^
> 
> Haha, that's a great typo :)
> 
> > be a UUID (as you can see above there is no evidence that Microsoft
> > who wrote the original spec thought it was).  Following from this
> > incorrect assumption, they stated that the "UUID" must be supplied to
> > qemu in big endian format and must be byteswapped when writing it to
> > guest memory.  Their documentation says that they only do this for
> > little endian guests, but this is not true of their implementation
> > which byte swaps it for all guests.
> 
> I don't think this is what section "Endian-ness Considerations" in
> "docs/specs/vmgenid.txt" says. That text says that the *device* uses
> little-endian format. That's independent of the endianness of *CPU* of
> the particular guest architecture.
> 
> So the byte-swapping in the QEMU code occurs unconditionally because
> QEMU's UUID type is inherently big endian, and the device model in
> question is fixed little endian. The guest CPU's endianness is
> irrelevant as far as the device is concerned.
> 
> If a BE guest CPU intends to read the generation ID and to interpret it
> as a set of integers, then the guest CPU is supposed to byte-swap the
> appropriate fields itself.
> 
> > References
> 
> I suggest adding two links in this section, namely to:
> - docs/specs/vmgenid.txt
> - hw/acpi/vmgenid.c

Fair enough - I've made the changes you suggest (same URL as above).

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top



      reply	other threads:[~2021-10-04 15:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1632900578.git.mprivozn@redhat.com>
2021-09-29  9:20 ` [PATCH 0/1] vmx: Fix <genid/> mapping Richard W.M. Jones
2021-09-29  9:33   ` Daniel P. Berrangé
2021-09-29  9:46     ` Richard W.M. Jones
2021-09-29 10:07       ` Daniel P. Berrangé
2021-09-29 10:24         ` Richard W.M. Jones
2021-09-29 10:24       ` Richard W.M. Jones
2021-09-29  9:57     ` Richard W.M. Jones
2021-09-29 10:10       ` Daniel P. Berrangé
2021-09-29 10:34         ` Richard W.M. Jones
2021-09-30  7:33           ` Richard W.M. Jones
2021-09-30  8:35             ` Laszlo Ersek
2021-09-30  8:47             ` Daniel P. Berrangé
2021-09-30  9:16               ` Richard W.M. Jones
2021-10-04  9:59                 ` Richard W.M. Jones
2021-10-04 14:50                   ` Laszlo Ersek
2021-10-04 14:59                     ` Richard W.M. Jones [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211004145909.GZ3361@redhat.com \
    --to=rjones@redhat.com \
    --cc=acatan@amazon.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=lersek@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.