From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0nnt-0005PF-PF for qemu-devel@nongnu.org; Mon, 23 Nov 2015 04:52:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0nnp-0004k6-Nc for qemu-devel@nongnu.org; Mon, 23 Nov 2015 04:52:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0nnp-0004jy-Hw for qemu-devel@nongnu.org; Mon, 23 Nov 2015 04:52:53 -0500 Date: Mon, 23 Nov 2015 11:52:50 +0200 From: "Michael S. Tsirkin" Message-ID: <20151123114033-mutt-send-email-mst@redhat.com> References: <1448264471-25066-1-git-send-email-jasowang@redhat.com> <20151123103645.4c899f97.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151123103645.4c899f97.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [RFC] virtio: convert to use DMA api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Jason Wang , qemu-devel@nongnu.org On Mon, Nov 23, 2015 at 10:36:45AM +0100, Cornelia Huck wrote: > On Mon, 23 Nov 2015 15:41:11 +0800 > Jason Wang wrote: > > > Currently, all virtio devices bypass IOMMU completely. This is because > > address_space_memory is assumed and used during DMA emulation. This > > patch converts the virtio core API to use DMA API. This idea is > > > > - introducing a new transport specific helper to query the dma address > > space. (only pci version is implemented). > > - query and use this address space during virtio device guest memory > > accessing > > > > With this virtiodevices will not bypass IOMMU anymore. Little tested with > > intel_iommu=on with virtio guest DMA series posted in > > https://lkml.org/lkml/2015/10/28/64. > > > > TODO: > > - Feature bit for this > > I'm still not convinced about that feature bit stuff. It just feels > wrong to use a mechanism that conveys negotiable device features to > configure what is basically a platform/hypervisor feature. I'd rather > see this out of the virtio layer and into the pci layer. I agree it's not something that needs to be negotiated. But given that we are changing device and driver behaviour in a drastic way, it seems prudent to have a way for guest and host to discover that, even if it's just in case. Whether it's a feature bit or something else pci-specific, depends on whether this makes sense for any other transport. > > - Implement this for all transports > > Is it OK to just keep a fallback to today's implementation for > transports for which the iommu concept doesn't make sense and that will > always have an identity mapping? Is there a reason why iommu does not make any sense for ccw or mmio? > > > > Signed-off-by: Jason Wang > > --- > > hw/block/virtio-blk.c | 2 +- > > hw/char/virtio-serial-bus.c | 2 +- > > hw/scsi/virtio-scsi.c | 2 +- > > hw/virtio/virtio-pci.c | 9 +++++++++ > > hw/virtio/virtio.c | 36 +++++++++++++++++++-------------- > > include/hw/virtio/virtio-access.h | 42 +++++++++++++++++++++++++++++---------- > > include/hw/virtio/virtio-bus.h | 1 + > > include/hw/virtio/virtio.h | 2 +- > > 8 files changed, 67 insertions(+), 29 deletions(-) > > FWIW, this doesn't seem to break for the s390-ccw-virtio machine (only > snifftested).