From: "Richard W.M. Jones" <rjones@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
lersek@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [PATCH 0/1] vmx: Fix <genid/> mapping
Date: Thu, 30 Sep 2021 10:16:20 +0100 [thread overview]
Message-ID: <20210930091620.GX3361@redhat.com> (raw)
In-Reply-To: <YVV5hZmEs2NmbiiI@redhat.com>
On Thu, Sep 30, 2021 at 09:47:01AM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 30, 2021 at 08:33:48AM +0100, Richard W.M. Jones wrote:
> > I propose we deprecate the guid parameter in:
> >
> > -device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0
> >
> > Instead it will be replaced by bytes= which will simply write
> > the bytes, in the order they appear, into guest memory with no
> > attempt to interpret or byte-swap. Something like:
> >
> > -device vmgenid,bytes=112233445566778899aabbccddeeff00,id=vmgenid0
> >
> > (guid although deprecated will need to be kept around for a while,
> > along with its weird byte-swapping behaviour).
> >
> > We will then have a plain and simple method to emulate the behaviour
> > of other hypervisors. We will look at exactly what bytes they write
> > to guest memory and copy that behaviour when v2v converting from those
> > hypervisors.
>
> From the libvirt POV, I'm not expecting anything in QEMU to change
> in this respect. If guid is replaced by a new attribute taking data
> in a different way, then libvirt will have to remap itself, so that
> existing usage in libvirt keeps working the same way as it did with
> guid. Essentially from libvirt's POV, it is simply a documentation
> issue to specify how the libvirt XML representation translates to
> the guest visible representation, and ensure that all libvirt drivers
> implement it the same way. The QEMU genid support arrived first so
> that set the standard for how libvirt will represent it, that all
> further libvirt hypervisor drivers need to match.
I was going to suggest something like:
<genid type="guid">aa-bb-cc..</genid>
or
<genid type="binary">aabbcc..</genid>
with the type defaulting to guid for backwards compatibility.
Does libvirt XML have any other fields were you're passing
essentially small snippets of binary data?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
next prev parent reply other threads:[~2021-09-30 9:17 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 [this message]
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
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=20210930091620.GX3361@redhat.com \
--to=rjones@redhat.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.