[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324335400.2132.47.camel@shinybook.infradead.org>
Date: Mon, 19 Dec 2011 22:56:40 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Joerg Roedel <joerg.roedel@....com>,
Alex Williamson <alex.williamson@...hat.com>, aik@...abs.ru,
benh@...nel.crashing.org, chrisw@...hat.com, agraf@...e.de,
scottwood@...escale.com, B08248@...escale.com,
rusty@...tcorp.com.au, iommu@...ts.linux-foundation.org,
qemu-devel@...gnu.org, linux-kernel@...r.kernel.org,
joro@...tes.org
Subject: Re: [RFC] Device isolation infrastructure v2
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?
--
dwmw2
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5818 bytes)
Powered by blists - more mailing lists