From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "ehabkost@redhat.com" <ehabkost@redhat.com>,
Sergio Lopez <slp@redhat.com>,
"maran.wilson@oracle.com" <maran.wilson@oracle.com>,
"Montes, Julio" <julio.montes@intel.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"sgarzare@redhat.com" <sgarzare@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type
Date: Fri, 26 Jul 2019 07:10:04 -0400 [thread overview]
Message-ID: <20190726065653-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <65d0458b-02bf-0e40-2851-b4becc911e4f@redhat.com>
On Fri, Jul 26, 2019 at 09:57:51AM +0200, Paolo Bonzini wrote:
> On 25/07/19 22:30, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 05:35:01PM +0200, Paolo Bonzini wrote:
> >> On 25/07/19 16:46, Michael S. Tsirkin wrote:
> >>> Actually, I think I have a better idea.
> >>> At the moment we just get an exit on these reads and return all-ones.
> >>> Yes, in theory there could be a UR bit set in a bunch of
> >>> registers but in practice no one cares about these,
> >>> and I don't think we implement them.
> >>> So how about mapping a single page, read-only, and filling it
> >>> with all-ones?
> >>
> >> Yes, that's nice indeed. :) But it does have some cost, in terms of
> >> either number of VMAs or QEMU RSS since the MMCONFIG area is large.
> >>
> >> What breaks if we return all zeroes? Zero is not a valid vendor ID.
> >>
> >> Paolo
> >
> > I think I know what you are thinking of doing:
> > map /dev/zero so we get a single VMA but all mapped to
> > a single zero pte?
>
> Yes, exactly. You absolutely need to share the page because the guest
> could easily touch 32*256 pages just to scan function 0 on every bus and
> device, even if the VM has just 4 or 5 devices and all of them on the
> root complex. And that causes fragmentation so you have to map bigger
> areas.
>
> > - we can implement /dev/ones. in fact, we can implement
> > /dev/byteXX for each possible value, the cost will
> > be only 1M on a 4k page system.
> > it might come in handy for e.g. free page hinting:
> > at the moment if guest memory is poisoned
> > we can not unmap it, with this trick we can
> > map it to /dev/byteXX.
>
> I also thought of /dev/ones, not sure how it would be accepted. :) Also
> you cannot map lazily on page fault, otherwise you get a vmexit and it's
> slow again. So /dev/ones needs to be written to use a huge page, possibly.
>
> Paolo
It's not easy to do that - each device gets 4K within MCFG.
So what we need then is a kvm option to create an address range - or
maybe even a group of address ranges and aggressively map all pages in a
group to the same guest page on a fault of one page in the group.
--
MST
next prev parent reply other threads:[~2019-07-26 11:10 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 12:11 [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type Sergio Lopez
2019-07-02 12:11 ` [Qemu-devel] [PATCH v3 1/4] hw/virtio: Factorize virtio-mmio headers Sergio Lopez
2019-07-25 9:46 ` Liam Merwick
2019-07-25 9:58 ` Michael S. Tsirkin
2019-07-25 10:03 ` Peter Maydell
2019-07-25 10:36 ` Paolo Bonzini
2019-07-02 12:11 ` [Qemu-devel] [PATCH v3 2/4] hw/i386: Add an Intel MPTable generator Sergio Lopez
2019-07-02 12:11 ` [Qemu-devel] [PATCH v3 3/4] hw/i386: Factorize PVH related functions Sergio Lopez
2019-07-23 8:39 ` Liam Merwick
2019-07-02 12:11 ` [Qemu-devel] [PATCH v3 4/4] hw/i386: Introduce the microvm machine type Sergio Lopez
2019-07-02 13:58 ` Gerd Hoffmann
2019-07-25 10:47 ` Paolo Bonzini
2019-07-02 15:01 ` [Qemu-devel] [PATCH v3 0/4] " no-reply
2019-07-02 15:23 ` Peter Maydell
2019-07-02 17:34 ` Sergio Lopez
2019-07-02 18:04 ` Peter Maydell
2019-07-02 22:04 ` Sergio Lopez
2019-07-25 9:59 ` Michael S. Tsirkin
2019-07-25 10:05 ` Peter Maydell
2019-07-25 10:10 ` Michael S. Tsirkin
2019-07-25 14:52 ` Sergio Lopez
2019-07-25 10:42 ` Sergio Lopez
2019-07-25 11:23 ` Paolo Bonzini
2019-07-25 12:01 ` Stefan Hajnoczi
2019-07-25 12:10 ` Michael S. Tsirkin
2019-07-25 13:26 ` Stefan Hajnoczi
2019-07-25 13:43 ` Paolo Bonzini
2019-07-25 13:54 ` Michael S. Tsirkin
2019-07-25 14:13 ` Paolo Bonzini
2019-07-25 14:42 ` Michael S. Tsirkin
2019-07-25 14:04 ` Peter Maydell
2019-07-25 14:26 ` Paolo Bonzini
2019-07-25 14:35 ` Michael S. Tsirkin
2019-07-25 14:42 ` Sergio Lopez
2019-07-25 14:58 ` Michael S. Tsirkin
2019-07-25 15:01 ` Michael S. Tsirkin
2019-07-25 15:39 ` Paolo Bonzini
2019-07-25 17:38 ` Michael S. Tsirkin
2019-07-26 12:46 ` Igor Mammedov
2019-07-25 15:49 ` Sergio Lopez
2019-07-25 13:48 ` Michael S. Tsirkin
2019-07-02 15:30 ` no-reply
2019-07-03 9:58 ` Stefan Hajnoczi
2019-07-18 15:21 ` Sergio Lopez
2019-07-19 10:29 ` Stefan Hajnoczi
2019-07-19 13:48 ` Sergio Lopez
2019-07-19 15:09 ` Stefan Hajnoczi
2019-07-19 15:42 ` Montes, Julio
2019-07-23 8:43 ` Sergio Lopez
2019-07-23 9:47 ` Stefan Hajnoczi
2019-07-23 10:01 ` Paolo Bonzini
2019-07-24 11:14 ` Paolo Bonzini
2019-07-25 9:35 ` Sergio Lopez
2019-07-25 10:03 ` Michael S. Tsirkin
2019-07-25 10:55 ` Paolo Bonzini
2019-07-25 14:46 ` Michael S. Tsirkin
2019-07-25 15:35 ` Paolo Bonzini
2019-07-25 17:33 ` Michael S. Tsirkin
2019-07-25 20:30 ` Michael S. Tsirkin
2019-07-26 7:57 ` Paolo Bonzini
2019-07-26 11:10 ` Michael S. Tsirkin [this message]
2019-07-23 11:30 ` Stefano Garzarella
2019-07-24 15:23 ` Stefano Garzarella
2019-08-29 9:02 ` Jing Liu
2019-08-29 15:46 ` Sergio Lopez
2019-08-30 4:53 ` Jing Liu
2019-08-30 14:27 ` Sergio Lopez
2019-09-02 5:43 ` Jing Liu
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=20190726065653-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=julio.montes@intel.com \
--cc=kraxel@redhat.com \
--cc=maran.wilson@oracle.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=sgarzare@redhat.com \
--cc=slp@redhat.com \
--cc=stefanha@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).