From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff Date: Mon, 23 Nov 2015 09:56:56 +0200 Message-ID: <20151123095453-mutt-send-email-mst@redhat.com> References: <20151119153821-mutt-send-email-mst@redhat.com> <1447976286.145626.122.camel@infradead.org> <20151120085658-mutt-send-email-mst@redhat.com> <1448207908.89124.54.camel@infradead.org> <20151122231622-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: David Woodhouse Cc: linux-s390 , KVM , Marcel Apfelbaum , Benjamin Herrenschmidt , Sebastian Ott , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Christian Borntraeger , Joerg Roedel , Martin Schwidefsky , Paolo Bonzini , Linux Virtualization , Christoph Hellwig List-Id: virtualization@lists.linuxfoundation.org On Sun, Nov 22, 2015 at 10:21:34PM -0000, David Woodhouse wrote: > > > > There's that, and there's an "I care about security, but > > do not want to burn up cycles on fake protections that > > do not work" case. > > It would seem to make most sense for this use case simply *not* to expose > virtio devices to guests as being behind an IOMMU at all. Sure, there are > esoteric use cases where the guest actually nests and runs further guests > inside itself and wants to pass through the virtio devices from the real > hardware host. But presumably those configurations will have multiple > virtio devices assigned by the host anyway, and further tweaking the > configuration to put them behind an IOMMU shouldn't be hard. Unfortunately it's a no-go: this breaks the much less esoteric usecase of DPDK: using virtio devices with userspace drivers. Well - not breaks as such as this doesn't currently work, but this approach would prevent us from making it work. > > -- > dwmw2