From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGSAb-0006rC-Ke for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:10:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGSAW-0004kL-5n for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:10:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGSAV-0004kA-LV for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:10:36 -0400 Message-ID: <4E9E93F7.8080400@redhat.com> Date: Wed, 19 Oct 2011 11:10:15 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111002102547.GC30747@redhat.com> <4E883CF4.6060606@redhat.com> <20111002105238.GE30747@redhat.com> <4E8843DB.1020404@redhat.com> <20111002111700.GF30747@redhat.com> <4E885286.30905@redhat.com> <20111002121426.GK30747@redhat.com> <4E89B5D1.4080600@us.ibm.com> <20111014021407.GB4580@truffala.fritz.box> <4E9AD909.1000509@redhat.com> <20111018014650.GB6655@truffala.fritz.box> In-Reply-To: <20111018014650.GB6655@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/9] Add stub functions for PCI device models to do PCI DMA List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , "Michael S. Tsirkin" , qemu-devel@nongnu.org, joerg.roedel@amd.com, rth@twiddle.net, agraf@suse.de, eduard.munteanu@linux360.ro, kraxel@redhat.com, Paul 'Rusty' Russell On 10/18/2011 03:46 AM, David Gibson wrote: > On Sun, Oct 16, 2011 at 03:15:53PM +0200, Avi Kivity wrote: > > On 10/14/2011 04:14 AM, David Gibson wrote: > > > > Virtio is a very, very special case. virtio requires coherent RAM access. > > > > > > Right. Virtio's access to memory is *not* emulated PCI DMA, it's > > > god-like hypervisor access to guest system memory. It should > > > correctly bypass any IOMMU, and so should remain as > > > cpu_physical_memory_rw() or the atomic accessors, rather than being > > > converted to this new API. > > > > virtio should definitely not bypass an iommu. > > So, I just had a chat with Rusty about this. Perhaps it shouldn't, > but it does. The spec is in terms of guest physical addresses, not > bus/DMA addresses, and more to the point the Linux driver does *not* > do the necessary dma_map() and unmap operations to treat this as a PCI > DMA. So like it or not, god-like hypervisor access rather than > emulated PCI DMA is what it does. Wow, how did we manage to break virtio in so many different ways? Is there a way to unbreak it? On x86 it will continue to work if we rewrite the spec in terms of pci dma, what about non-x86? > > > A guest may assign a > > virtio device to nested guests, and would wish it confined by the > > emulated iommu. > > Well, that would be nice, but it can't be done. It could be fixed, > but it would be an incompatible change so it would need a new feature > bit corresponding changes in the Linux driver to do the dma map/unmap > if it accepts the "respect IOMMU" feature. Needs to be done IMO. > > > More generally, a guest sees a virtio device as just another pci device, > > and has no way to tell that it bypasses the iommu. > > Well, except the fact that the driver knows its a virtio device, > because it's a virtio driver. It's not like you can write a driver > that uses PCI DMA without knowing the particulars of the device you're > using. virtio-pci knows it's pci, there's no excuse. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.