From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Gal Hammer <ghammer@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device
Date: Wed, 4 Feb 2015 17:07:02 +0100 [thread overview]
Message-ID: <20150204160702.GA22311@redhat.com> (raw)
In-Reply-To: <20150204165354.5e7106c5@nial.brq.redhat.com>
On Wed, Feb 04, 2015 at 04:53:54PM +0100, Igor Mammedov wrote:
> > > > Isn't this will cause a VMEXIT when the guest is reading the GUID? If it
> > > > is then this idea was already presented and Michael didn't approve it.
> > > It will, but is it performance critical? VM supposed to read it
> > > at start-up and on getting notification. So I think VMEXIT in this case
> > > is not sufficient to drop simple and strait-forward design.
> >
> > I agree with you on that and one of the previous patches did used a fixed-address to store the GUID while read/write access were handled by qemu driver code. But as I wrote before, it was Michael who didn't approved it so I proposed this method although it is a bit more complicated.
> >
> > I don't know how to break out of this dead-lock... :(
> Could you post a link to driver based version of series.
> Perhaps we could address Michael's comments and still stay
> with a simple implementation.
The point is to keep all allocations in guest.
I don't want to "steal" a page from guest.
> >
> > >
> > > BTW:
> > > For start-up fw_cfg file is not any way better, it's also causes VMEXIT
> > > for every byte it reads from it.
> >
> > I don't understand your claim. Accessing the fw_cfg "file" doesn't cause VMEXIT as it located somewhere in the guest's memory range.
> As far as I'm aware MMIO or ioport is used for reading fw_cfg contents
> on guest side, one byte at a time and every such access causes VMEXIT
> into QEMU callback.
It's highly unlikely to be measureable. Prove me wrong if you like.
--
MST
next prev parent reply other threads:[~2015-02-04 16:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-16 15:50 [Qemu-devel] [PATCH V11 0/3] Virtual Machine Generation ID Gal Hammer
2014-12-16 15:50 ` [Qemu-devel] [PATCH V11 1/3] docs: vm generation id device's description Gal Hammer
2014-12-16 15:50 ` [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device Gal Hammer
2015-01-22 13:52 ` Igor Mammedov
2015-01-22 21:21 ` Michael S. Tsirkin
2015-02-01 12:56 ` Gal Hammer
2015-02-02 12:46 ` Igor Mammedov
2015-02-02 13:13 ` Gal Hammer
2015-02-02 13:55 ` Igor Mammedov
2015-02-04 15:09 ` Gal Hammer
2015-02-04 15:53 ` Igor Mammedov
2015-02-04 16:07 ` Michael S. Tsirkin [this message]
2014-12-16 15:50 ` [Qemu-devel] [PATCH V11 3/3] tests: add a unit test for the vmgenid device Gal Hammer
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=20150204160702.GA22311@redhat.com \
--to=mst@redhat.com \
--cc=ghammer@redhat.com \
--cc=imammedo@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.