From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXwLT-0005h0-95 for qemu-devel@nongnu.org; Fri, 25 May 2012 11:22:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXwLR-0004Cx-4t for qemu-devel@nongnu.org; Fri, 25 May 2012 11:22:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXwLQ-0004CM-TO for qemu-devel@nongnu.org; Fri, 25 May 2012 11:22:25 -0400 Message-ID: <4FBFA39B.8080805@redhat.com> Date: Fri, 25 May 2012 11:22:03 -0400 From: Don Dutile MIME-Version: 1.0 References: <20120522043607.5871.11340.stgit@bling.home> <20120522050536.5871.65171.stgit@bling.home> <4FBEAA5C.4060105@redhat.com> <1337899615.4714.79.camel@ul30vt> In-Reply-To: <1337899615.4714.79.camel@ul30vt> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 09/13] vfio: x86 IOMMU implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: aafabbri@cisco.com, kvm@vger.kernel.org, B07421@freescale.com, aik@ozlabs.ru, konrad.wilk@oracle.com, linux-pci@vger.kernel.org, agraf@suse.de, qemu-devel@nongnu.org, chrisw@sous-sol.org, B08248@freescale.com, iommu@lists.linux-foundation.org, gregkh@linuxfoundation.org, avi@redhat.com, joerg.roedel@amd.com, bhelgaas@google.com, benve@cisco.com, dwmw2@infradead.org, linux-kernel@vger.kernel.org, david@gibson.dropbear.id.au On 05/24/2012 06:46 PM, Alex Williamson wrote: > On Thu, 2012-05-24 at 17:38 -0400, Don Dutile wrote: >> On 05/22/2012 01:05 AM, Alex Williamson wrote: >>> x86 is probably the wrong name for this VFIO IOMMU driver, but x86 >>> is the primary target for it. This driver support a very simple >>> usage model using the existing IOMMU API. The IOMMU is expected to >>> support the full host address space with no special IOVA windows, >>> number of mappings restrictions, or unique processor target options. >>> >>> Signed-off-by: Alex Williamson >>> --- >>> >>> Documentation/ioctl/ioctl-number.txt | 2 >>> drivers/vfio/Kconfig | 6 >>> drivers/vfio/Makefile | 2 >>> drivers/vfio/vfio.c | 7 >>> drivers/vfio/vfio_iommu_x86.c | 743 ++++++++++++++++++++++++++++++++++ >>> include/linux/vfio.h | 52 ++ >>> 6 files changed, 811 insertions(+), 1 deletions(-) >>> create mode 100644 drivers/vfio/vfio_iommu_x86.c >>> >>> diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt >>> index 111e30a..9d1694e 100644 >>> --- a/Documentation/ioctl/ioctl-number.txt >>> +++ b/Documentation/ioctl/ioctl-number.txt >>> @@ -88,7 +88,7 @@ Code Seq#(hex) Include File Comments >>> and kernel/power/user.c >>> '8' all SNP8023 advanced NIC card >>> >>> -';' 64-6F linux/vfio.h >>> +';' 64-72 linux/vfio.h >>> '@' 00-0F linux/radeonfb.h conflict! >>> '@' 00-0F drivers/video/aty/aty128fb.c conflict! >>> 'A' 00-1F linux/apm_bios.h conflict! >>> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig >>> index 9acb1e7..bd88a30 100644 >>> --- a/drivers/vfio/Kconfig >>> +++ b/drivers/vfio/Kconfig >>> @@ -1,6 +1,12 @@ >>> +config VFIO_IOMMU_X86 >>> + tristate >>> + depends on VFIO&& X86 >>> + default n >>> + >>> menuconfig VFIO >>> tristate "VFIO Non-Privileged userspace driver framework" >>> depends on IOMMU_API >>> + select VFIO_IOMMU_X86 if X86 >>> help >>> VFIO provides a framework for secure userspace device drivers. >>> See Documentation/vfio.txt for more details. >> >> So a future refactoring that uses some chunk of this support >> on a non-x86 machine could be a lot of useless renaming. >> >> Why not rename vfio_iommu_x86 to something like vfio_iommu_no_iova >> and just make it conditionally compiled on X86 (as you've done above in Kconfig's)? >> Then if another arch can use it, or refactors the file to use >> some of it, and split x86 vs into separate per-arch files, >> or per-iova schemes, it's more descriptive and less disruptive? > > Yep, the problem is how to concisely describe what we expect to support > here. This file supports IOMMU API based usage of an IOMMU with > effectively no DMA window or mapping constraints, optimized for static > mapping of an address space. What's a good name for that? Maybe I > should follow the example of others and just call it a Type 1 IOMMU > implementation so the marketing material looks better! ;-P That may > honestly be better than calling it x86. Thoughts? Thanks, > > Alex > I'll vote for 'type1' over 'x86' .... Add a comment in the file what a 'type1 IOMMU' is. Then others can dupe format for typeX. > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html