From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752934AbbKVXEP (ORCPT ); Sun, 22 Nov 2015 18:04:15 -0500 Received: from twosheds.infradead.org ([90.155.92.209]:34069 "EHLO twosheds.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752193AbbKVXEM (ORCPT ); Sun, 22 Nov 2015 18:04:12 -0500 Message-ID: In-Reply-To: <20151122231622-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> Date: Sun, 22 Nov 2015 22:21:34 -0000 Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff From: "David Woodhouse" To: "Michael S. Tsirkin" Cc: "David Woodhouse" , "Andy Lutomirski" , "Benjamin Herrenschmidt" , "Christian Borntraeger" , "Paolo Bonzini" , "linux-kernel@vger.kernel.org" , "Martin Schwidefsky" , "Sebastian Ott" , "linux-s390" , "Cornelia Huck" , "Joerg Roedel" , "Linux Virtualization" , "Christoph Hellwig" , "KVM" , "Marcel Apfelbaum" User-Agent: SquirrelMail/1.4.22-15.fc21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David Woodhouse" Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff Date: Sun, 22 Nov 2015 22:21:34 -0000 Message-ID: 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: In-Reply-To: <20151122231622-mutt-send-email-mst@redhat.com> 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 List-Archive: List-Post: To: "Michael S. Tsirkin" 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 , David Woodhouse , Christoph Hellwig List-ID: > 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. -- dwmw2