From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:36176)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1UVknK-0004Iq-Kq
	for qemu-devel@nongnu.org; Fri, 26 Apr 2013 11:42:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1UVknG-000084-0f
	for qemu-devel@nongnu.org; Fri, 26 Apr 2013 11:42:42 -0400
Received: from mx1.redhat.com ([209.132.183.28]:5851)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1UVknF-00007s-Ov
	for qemu-devel@nongnu.org; Fri, 26 Apr 2013 11:42:37 -0400
Message-ID: <1366990951.16887.11.camel@ul30vt.home>
From: Alex Williamson <alex.williamson@redhat.com>
Date: Fri, 26 Apr 2013 09:42:31 -0600
In-Reply-To: <1366956141-2066-1-git-send-email-david@gibson.dropbear.id.au>
References: <1366956141-2066-1-git-send-email-david@gibson.dropbear.id.au>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [0/4] RFC: Preparations for VFIO and guest IOMMUs
	(v2)
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aik@ozlabs.ru, pbonzini@redhat.com, qemu-devel@nongnu.org

On Fri, 2013-04-26 at 16:02 +1000, David Gibson wrote:
> This patch series represents a second attempt at better integration of
> the vfio code with qemu's handling of guest IOMMUs.  It is based on
> Paolo Bonzini's tree at git://github.com/bonzini/qemu.git (iommu
> branch).
> 
> ddThis series should open 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.
> 
> Patch 1 is just a trivial fix for a build problem introduced in the
> iommu tree.

I support what this series is trying to achieve, but not how it does it.
vfio needs to be just another driver, the ugliness and heavy lifting
should be done in vfio or the common should should be extended to
generically support the hooks that vfio needs.  We can't just drop vfio
pointers and callbacks into unrelated code.  Thanks,

Alex