[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1446135536.3405.279.camel@infradead.org>
Date: Thu, 29 Oct 2015 17:18:56 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>,
Andy Lutomirski <luto@...capital.net>
Cc: Christian Borntraeger <borntraeger@...ibm.com>,
Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Joerg Roedel <jroedel@...e.de>,
Cornelia Huck <cornelia.huck@...ibm.com>,
Sebastian Ott <sebott@...ux.vnet.ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Christoph Hellwig <hch@....de>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
KVM <kvm@...r.kernel.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-s390 <linux-s390@...r.kernel.org>,
Linux Virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff
On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
>
> Example: you have a mix of assigned devices and virtio devices. You
> don't trust your assigned device vendor not to corrupt your memory so
> you want to limit the damage your assigned device can do to your
> guest,
> so you use an IOMMU for that. Thus existing iommu=pt within guest is
> out.
>
> But you trust your hypervisor (you have no choice anyway),
> and you don't want the overhead of tweaking IOMMU
> on data path for virtio. Thus iommu=on is out too.
That's not at all special for virtio or guest VMs. Even with real
hardware, we might want performance from *some* devices, and security
from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being
discussed.
But of course the easy answer in *your* case it just to ask the
hypervisor not to put the virtio devices behind an IOMMU at all. Which
we were planning to remain the default behaviour.
In all cases, the DMA API shall do the right thing.
--
dwmw2
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)
Powered by blists - more mailing lists