From: David Gibson <david@gibson.dropbear.id.au>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
Alex Williamson <alex.williamson@redhat.com>,
aik@ozlabs.ru, benh@kernel.crashing.org, chrisw@redhat.com,
agraf@suse.de, scottwood@freescale.com, B08248@freescale.com,
rusty@rustcorp.com.au, iommu@lists.linux-foundation.org,
qemu-devel@nongnu.org, linux-kernel@vger.kernel.org,
joro@8bytes.org
Subject: Re: [RFC] Device isolation infrastructure v2
Date: Tue, 20 Dec 2011 11:25:15 +1100 [thread overview]
Message-ID: <20111220002515.GA5133@truffala.fritz.box> (raw)
In-Reply-To: <1324335400.2132.47.camel@shinybook.infradead.org>
On Mon, Dec 19, 2011 at 10:56:40PM +0000, David Woodhouse wrote:
> On Tue, 2011-12-20 at 09:31 +1100, David Gibson wrote:
> > When we're running paravirtualized under pHyp, it's impossible to
> > merge multiple PEs into one domain per se. We could fake it rather
> > nastily by replicating all map/unmaps across mutiple PEs. When
> > running bare metal, we could do so a bit more nicely by assigning
> > multiple PEs the same TCE pointer, but we have no mechanism to do so
> > at present.
>
> VT-d does share the page tables, as you could on bare metal. But it's an
> implementation detail — there's nothing *fundamentally* wrong with
> having to do the map/unmap for each PE, is there? It's only at VM setup
> time, so it doesn't really matter if it's slow.
>
> Surely that's the only way you're going to present the guest with the
> illusion of having no IOMMU; so that DMA to any given guest physical
> address "just works".
>
> On the other hand, perhaps you don't want to do that at all. Perhaps
> you're better off presenting a virtualised IOMMU to the guest and
> *insisting* that it fully uses it in order to do any DMA at all?
Not only do we want to, we more or less *have* to. Existing kernels,
which are used to being paravirt under phyp expect and need a paravirt
iommu. DMA without iommu setup just doesn't happen. And the
map/unmap hypercalls are frequently a hot path, so slow does matter.
The other problem is that each domain's IOVA window is often fairly
small, a limitation that would get even worse if we try to put too
many devices in there.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: David Woodhouse <dwmw2@infradead.org>
Cc: chrisw@redhat.com, aik@ozlabs.ru,
Joerg Roedel <joerg.roedel@amd.com>,
joro@8bytes.org, rusty@rustcorp.com.au, agraf@suse.de,
iommu@lists.linux-foundation.org, qemu-devel@nongnu.org,
B08248@freescale.com,
Alex Williamson <alex.williamson@redhat.com>,
scottwood@freescale.com, linux-kernel@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC] Device isolation infrastructure v2
Date: Tue, 20 Dec 2011 11:25:15 +1100 [thread overview]
Message-ID: <20111220002515.GA5133@truffala.fritz.box> (raw)
In-Reply-To: <1324335400.2132.47.camel@shinybook.infradead.org>
On Mon, Dec 19, 2011 at 10:56:40PM +0000, David Woodhouse wrote:
> On Tue, 2011-12-20 at 09:31 +1100, David Gibson wrote:
> > When we're running paravirtualized under pHyp, it's impossible to
> > merge multiple PEs into one domain per se. We could fake it rather
> > nastily by replicating all map/unmaps across mutiple PEs. When
> > running bare metal, we could do so a bit more nicely by assigning
> > multiple PEs the same TCE pointer, but we have no mechanism to do so
> > at present.
>
> VT-d does share the page tables, as you could on bare metal. But it's an
> implementation detail — there's nothing *fundamentally* wrong with
> having to do the map/unmap for each PE, is there? It's only at VM setup
> time, so it doesn't really matter if it's slow.
>
> Surely that's the only way you're going to present the guest with the
> illusion of having no IOMMU; so that DMA to any given guest physical
> address "just works".
>
> On the other hand, perhaps you don't want to do that at all. Perhaps
> you're better off presenting a virtualised IOMMU to the guest and
> *insisting* that it fully uses it in order to do any DMA at all?
Not only do we want to, we more or less *have* to. Existing kernels,
which are used to being paravirt under phyp expect and need a paravirt
iommu. DMA without iommu setup just doesn't happen. And the
map/unmap hypercalls are frequently a hot path, so slow does matter.
The other problem is that each domain's IOVA window is often fairly
small, a limitation that would get even worse if we try to put too
many devices in there.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2011-12-20 0:25 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 6:25 [RFC] Device isolation infrastructure v2 David Gibson
2011-12-15 6:25 ` [Qemu-devel] " David Gibson
2011-12-15 6:25 ` [PATCH 1/3] device_isolation: Infrastructure for managing device isolation groups David Gibson
2011-12-15 6:25 ` [Qemu-devel] " David Gibson
2011-12-15 6:25 ` [PATCH 2/3] device_isolation: Support isolation on POWER p5ioc2 bridges David Gibson
2011-12-15 6:25 ` [Qemu-devel] " David Gibson
2011-12-15 6:25 ` [PATCH 3/3] device_isolation: Support isolation on POWER p7ioc (IODA) bridges David Gibson
2011-12-15 6:25 ` [Qemu-devel] " David Gibson
2011-12-15 18:05 ` [RFC] Device isolation infrastructure v2 Alex Williamson
2011-12-15 18:05 ` [Qemu-devel] " Alex Williamson
2011-12-15 22:39 ` Alex Williamson
2011-12-15 22:39 ` [Qemu-devel] " Alex Williamson
2011-12-16 1:40 ` David Gibson
2011-12-16 1:40 ` [Qemu-devel] " David Gibson
2011-12-16 4:49 ` Alex Williamson
2011-12-16 4:49 ` [Qemu-devel] " Alex Williamson
2011-12-16 6:00 ` David Gibson
2011-12-16 6:00 ` [Qemu-devel] " David Gibson
2011-12-16 14:53 ` Joerg Roedel
2011-12-16 14:53 ` [Qemu-devel] " Joerg Roedel
2011-12-19 0:11 ` David Gibson
2011-12-19 0:11 ` [Qemu-devel] " David Gibson
2011-12-19 15:41 ` Joerg Roedel
2011-12-19 15:41 ` [Qemu-devel] " Joerg Roedel
2011-12-21 3:32 ` David Gibson
2011-12-21 3:32 ` David Gibson
2011-12-21 4:30 ` Alex Williamson
2011-12-21 4:30 ` Alex Williamson
2011-12-21 6:12 ` Aaron Fabbri
2011-12-21 6:12 ` Aaron Fabbri
[not found] ` <1324441837.29699.38.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-01-25 3:13 ` David Gibson
2012-01-25 3:13 ` David Gibson
2012-01-25 3:13 ` David Gibson
2012-01-25 23:44 ` Alex Williamson
2012-01-25 23:44 ` [Qemu-devel] " Alex Williamson
2012-01-25 23:44 ` Alex Williamson
[not found] ` <1327535093.26484.190.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-01-30 23:22 ` David Gibson
2012-01-30 23:22 ` David Gibson
2012-01-30 23:22 ` David Gibson
2011-12-21 16:46 ` Joerg Roedel
2011-12-21 16:46 ` Joerg Roedel
2011-12-19 15:46 ` David Woodhouse
2011-12-19 15:46 ` [Qemu-devel] " David Woodhouse
2011-12-19 22:31 ` David Gibson
2011-12-19 22:31 ` [Qemu-devel] " David Gibson
2011-12-19 22:56 ` David Woodhouse
2011-12-19 22:56 ` [Qemu-devel] " David Woodhouse
2011-12-20 0:25 ` David Gibson [this message]
2011-12-20 0:25 ` David Gibson
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=20111220002515.GA5133@truffala.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=B08248@freescale.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=chrisw@redhat.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=scottwood@freescale.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 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.