From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Pawel Moll <pawel.moll@arm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
virtualization <virtualization@lists.linux-foundation.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
Date: Thu, 12 Jan 2012 07:56:41 +1100 [thread overview]
Message-ID: <1326315401.23910.138.camel@pasglop> (raw)
In-Reply-To: <CAJSP0QVm2f+A8hFa+tx3LRcXa_oe8mn4=DhrGMnozVB8_K4OxQ@mail.gmail.com>
On Wed, 2012-01-11 at 17:21 +0000, Stefan Hajnoczi wrote:
> > It won't be hard to show siginificant performance regression if
> > we do this. Hard to justify for something as niche as nested virt.
>
> For x86 this should be mostly a nop.
No it won't be. Or rather, it will be as long as you map your entire
guests in the iommu, which means your entire guest will have to be
pinned and you lost swap, ksm, yadadada...
Since the only way to have non-pinned guests today on x86 is to use
virtio, you just shot yourself in the foot.
Eventually x86 will have to grow some kind of virtualized iommu or
paravir iommu to overcome that at which point you will pay that price.
> For ppc and SPARC architectures
> maybe you're right. I still think it's a design flaw because if
> virtio v2 doesn't use bus addresses then it will simply not be
> possible to do passthrough for nested virt and other cases we haven't
> hit yet.
Then don't use virtio in those cases, use real emulated HW. Seriously,
is nested virt that interesting ?
At the very least, make that use of iommu a feature or something like
that so it can be negociated down when not doing nesting which is going
to be 99% of your use cases.
Cheers,
Ben.
next prev parent reply other threads:[~2012-01-11 20:56 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 10:22 [PATCH 0/11] RFC: PCI using capabilitities Rusty Russell
2011-12-08 10:30 ` [RFC 1/11] virtio: use u32, not bitmap for struct virtio_device's features Rusty Russell
2011-12-08 10:31 ` [RFC 2/11] virtio: add support for 64 bit features Rusty Russell
2011-12-08 10:32 ` [PATCH 0/11] RFC: PCI using capabilitities Sasha Levin
2011-12-08 10:32 ` [RFC 3/11] pci: add pci_iomap_range Rusty Russell
2011-12-15 8:30 ` Michael S. Tsirkin
2011-12-16 1:56 ` Rusty Russell
2011-12-08 10:34 ` [RFC 4/11] virtio-pci: define layout for virtio vendor-specific capabilities Rusty Russell
2011-12-10 21:14 ` Sasha Levin
2011-12-08 10:35 ` [RFC 6/11] virtio_pci: move old defines to legacy, introduce new structure Rusty Russell
2011-12-08 10:38 ` [RFC 6/11] virtio_pci: don't use the legacy driver if we find the new PCI capabilities Rusty Russell
2011-12-10 21:18 ` Sasha Levin
2011-12-11 5:15 ` Rusty Russell
2011-12-11 9:37 ` Michael S. Tsirkin
2011-12-08 10:39 ` [RFC 7/11] virtio_pci: new, capability-aware driver Rusty Russell
2011-12-11 9:42 ` Michael S. Tsirkin
2011-12-11 22:45 ` Rusty Russell
2011-12-12 11:49 ` Michael S. Tsirkin
2011-12-12 18:10 ` Don Dutile
2011-12-16 1:58 ` Rusty Russell
2013-05-28 7:56 ` Michael S. Tsirkin
2013-05-29 1:17 ` Rusty Russell
2013-05-29 10:21 ` Michael S. Tsirkin
2013-05-30 2:17 ` Rusty Russell
2011-12-12 18:25 ` Michael S. Tsirkin
2011-12-13 2:21 ` Rusty Russell
2011-12-15 8:27 ` Michael S. Tsirkin
2011-12-16 1:50 ` Rusty Russell
2011-12-18 10:18 ` Michael S. Tsirkin
2011-12-19 6:06 ` Rusty Russell
2011-12-19 9:13 ` Michael S. Tsirkin
2011-12-19 11:08 ` Rusty Russell
2011-12-20 11:37 ` Michael S. Tsirkin
2011-12-21 0:33 ` Rusty Russell
2011-12-21 9:19 ` Michael S. Tsirkin
2012-01-10 17:03 ` Michael S. Tsirkin
2012-01-11 0:25 ` Rusty Russell
2012-01-11 1:48 ` Benjamin Herrenschmidt
2012-01-11 8:47 ` Stefan Hajnoczi
2012-01-11 9:10 ` Benjamin Herrenschmidt
2012-01-11 14:28 ` Stefan Hajnoczi
2012-01-11 15:39 ` Michael S. Tsirkin
2012-01-11 17:21 ` Stefan Hajnoczi
2012-01-11 18:34 ` Michael S. Tsirkin
2012-01-11 20:56 ` Benjamin Herrenschmidt [this message]
2012-01-11 20:46 ` Benjamin Herrenschmidt
2012-01-12 10:37 ` Stefan Hajnoczi
2012-01-11 10:21 ` Michael S. Tsirkin
2012-01-11 21:13 ` Benjamin Herrenschmidt
2012-01-11 22:13 ` Michael S. Tsirkin
2012-01-11 22:19 ` Benjamin Herrenschmidt
2012-01-11 22:56 ` Benjamin Herrenschmidt
2012-01-12 5:29 ` Michael S. Tsirkin
2012-01-12 6:13 ` Benjamin Herrenschmidt
2012-01-12 6:37 ` Michael S. Tsirkin
2012-01-12 2:01 ` Rusty Russell
2012-01-12 4:31 ` Benjamin Herrenschmidt
2012-01-12 6:09 ` Michael S. Tsirkin
2012-01-12 6:28 ` Benjamin Herrenschmidt
2012-01-12 6:51 ` Michael S. Tsirkin
2012-01-12 7:03 ` Benjamin Herrenschmidt
2012-01-12 6:00 ` Michael S. Tsirkin
2012-01-13 3:22 ` Rusty Russell
2012-01-11 13:30 ` Anthony Liguori
2012-01-11 15:12 ` Michael S. Tsirkin
2012-01-11 15:15 ` Anthony Liguori
2012-01-11 15:21 ` Michael S. Tsirkin
2012-01-11 15:28 ` Anthony Liguori
2012-01-11 15:45 ` Michael S. Tsirkin
2012-01-11 16:02 ` Anthony Liguori
2012-01-11 17:08 ` Michael S. Tsirkin
2012-01-11 19:42 ` Anthony Liguori
2012-01-11 20:14 ` Michael S. Tsirkin
2012-01-11 20:26 ` Anthony Liguori
2012-01-11 21:02 ` Benjamin Herrenschmidt
2012-01-11 22:02 ` Michael S. Tsirkin
2012-01-11 22:16 ` Benjamin Herrenschmidt
2012-01-12 1:42 ` Rusty Russell
2012-01-13 2:19 ` Michael S. Tsirkin
2012-01-13 2:32 ` Benjamin Herrenschmidt
2012-01-18 15:29 ` Michael S. Tsirkin
2012-01-22 22:53 ` Rusty Russell
2012-01-18 4:52 ` Rusty Russell
2012-01-11 21:58 ` Michael S. Tsirkin
2012-01-11 20:59 ` Benjamin Herrenschmidt
2012-01-11 20:51 ` Benjamin Herrenschmidt
2012-01-11 20:50 ` Benjamin Herrenschmidt
2012-01-12 1:35 ` Rusty Russell
2011-12-08 10:40 ` [RFC 8/11] virtio_pci: share structure between legacy and modern Rusty Russell
2011-12-08 10:41 ` [RFC 9/11] virtio_pci: share interrupt/notify handlers " Rusty Russell
2011-12-08 10:42 ` [RFC 10/11] virtio_pci: share virtqueue setup/teardown between modern and legacy driver Rusty Russell
2011-12-08 10:44 ` [RFC 11/11] virtio_pci: simplify common helpers Rusty Russell
2011-12-08 15:37 ` [PATCH 0/11] RFC: PCI using capabilitities Sasha Levin
[not found] ` <1323358657.32487.9.camel@lappy>
2011-12-09 6:17 ` Rusty Russell
2011-12-10 21:32 ` Sasha Levin
2011-12-11 9:05 ` Avi Kivity
2011-12-11 10:03 ` Sasha Levin
2011-12-11 12:30 ` Michael S. Tsirkin
2011-12-11 12:48 ` Sasha Levin
2011-12-11 12:47 ` Michael S. Tsirkin
2011-12-11 12:53 ` Sasha Levin
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=1326315401.23910.138.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=levinsasha928@gmail.com \
--cc=mst@redhat.com \
--cc=pawel.moll@arm.com \
--cc=stefanha@gmail.com \
--cc=virtualization@lists.linux-foundation.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 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).