From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNSNF-0003Of-6J for qemu-devel@nongnu.org; Wed, 03 Apr 2013 14:25:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNSND-0002vp-Ic for qemu-devel@nongnu.org; Wed, 03 Apr 2013 14:25:29 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:33442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNSND-0002ve-Ct for qemu-devel@nongnu.org; Wed, 03 Apr 2013 14:25:27 -0400 Received: by mail-pd0-f182.google.com with SMTP id 3so993063pdj.13 for ; Wed, 03 Apr 2013 11:25:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1364958751.2882.209.camel@bling.home> References: <1364942646.24520.27@snotra> <1364958751.2882.209.camel@bling.home> Date: Wed, 3 Apr 2013 13:25:26 -0500 Message-ID: From: Stuart Yoder Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "agraf@suse.de" , "qemu-devel@nongnu.org" , Yoder Stuart-B08248 , "iommu@lists.linux-foundation.org" , Bhushan Bharat-R65777 , Scott Wood >> > Type1 is arbitrary. It might as well be named "brown" and this one >> > can be >> > "blue". >> >> The difference is that "type1" seems to refer to hardware that can do >> arbitrary 4K page mappings, possibly constrained by an aperture but >> nothing else. More than one IOMMU can reasonably fit that. The odds >> that another IOMMU would have exactly the same restrictions as PAMU >> seem smaller in comparison. >> >> In any case, if you had to deal with some Intel-only quirk, would it >> make sense to call it a "type1 attribute"? I'm not advocating one way >> or the other on whether an abstraction is viable here (though Stuart >> seems to think it's "highly unlikely anything but a PAMU will comply"), >> just that if it is to be abstracted rather than a hardware-specific >> interface, we need to document what is and is not part of the >> abstraction. Otherwise a non-PAMU-specific user won't know what they >> can rely on, and someone adding support for a new windowed IOMMU won't >> know if theirs is close enough, or they need to introduce a "type3". > > So Alexey named the SPAPR IOMMU something related to spapr... > surprisingly enough. I'm fine with that. If you think it's unique > enough, name it something appropriately. I haven't seen the code and > don't know the architecture sufficiently to have an opinion. The only reason I suggested "type 2" is that I thought that was the convention...we would enumerate different iommus. I think that calling it "pamu" is better and more clear. Stuart