From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdFQ5-00073M-DD for qemu-devel@nongnu.org; Wed, 21 Dec 2011 01:12:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdFQ3-0004yj-HV for qemu-devel@nongnu.org; Wed, 21 Dec 2011 01:12:53 -0500 Received: from mtv-iport-3.cisco.com ([173.36.130.14]:11213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdFQ3-0004yS-8r for qemu-devel@nongnu.org; Wed, 21 Dec 2011 01:12:51 -0500 Date: Tue, 20 Dec 2011 22:12:45 -0800 From: Aaron Fabbri Message-ID: In-Reply-To: <1324441837.29699.38.camel@bling.home> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Device isolation infrastructure v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , David Gibson Cc: chrisw@redhat.com, aik@ozlabs.ru, rusty@rustcorp.com.au, agraf@suse.de, qemu-devel@nongnu.org, B08248@freescale.com, iommu@lists.linux-foundation.org, scottwood@freescale.com, David Woodhouse , linux-kernel@vger.kernel.org On 12/20/11 8:30 PM, "Alex Williamson" wrote: > On Wed, 2011-12-21 at 14:32 +1100, David Gibson wrote: >> On Mon, Dec 19, 2011 at 04:41:56PM +0100, Joerg Roedel wrote: >>> On Mon, Dec 19, 2011 at 11:11:25AM +1100, David Gibson wrote: >>> >>> Well, the iommu-api was designed for amd-vi and vt-d. But its concepts >>> turn out to be more general and by no way x86-centric anymore. >> >> It's improving, but there are still plenty of x86isms there. > > Having worked on ia64 for a while, it's interesting to see this x86 > bashing from the other side. Everyone is more than willing to make > architecture neutral interfaces (jeez, look at the extent of the vfio > reworks), but it's not fair to throw away interfaces as x86-centric if > you're not pushing your requirements and making use of the code. > > It seems like we'd be better served today to start with the vfio code we > have and let that be the catalyst to drive an iommu api that better > serves non-x86. I don't see how this group management tangent is really > getting us anywhere. Thanks, I'd agree that incremental approach here is key. VFIO has already seen a ton of rework to accommodate all architectures. Let's not bite off a bunch of these other subsystem rewrites in the same chunk as our VFIO effort. -Aaron