From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUyYi-0005pD-T7 for qemu-devel@nongnu.org; Wed, 24 Apr 2013 08:12:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUyYa-0003lM-PB for qemu-devel@nongnu.org; Wed, 24 Apr 2013 08:12:24 -0400 Received: from ozlabs.org ([203.10.76.45]:45695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUyOQ-0008IP-1R for qemu-devel@nongnu.org; Wed, 24 Apr 2013 08:01:46 -0400 From: David Gibson Date: Wed, 24 Apr 2013 22:01:16 +1000 Message-Id: <1366804881-553-1-git-send-email-david@gibson.dropbear.id.au> Subject: [Qemu-devel] [0/5] RFC: Preparations for supporting VFIO with guest IOMMUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alex.williamson@redhat.com, aik@ozlabs.ru Cc: qemu-devel@nongnu.org This patch series represents my attempt at better integration of the vfio code with qemu's DMAContext and other guest IOMMU handling code, as discussed by Alex Williamson and myself on IRC. It opens the way for using VFIO with a guest system containing an IOMMU by passing guest IOMMU operations through to the host IOMMU via VFIO. That's opposed to the present model of having no IOMMU in the guest, and simply mapping all guest RAM into the host IOMMU. I hit some complications with some changes in the guest iommu infrastructure since it went in. Patches 1 & 2 clean that up, patches 3-5 do the necessary VFIO infrastructure changes.