linux-kernel - Re: [PATCH v2 09/13] vfio: x86 IOMMU implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 25 May 2012 11:22:03 -0400
From:	Don Dutile <ddutile@...hat.com>
To:	Alex Williamson <alex.williamson@...hat.com>
CC:	benh@...nel.crashing.org, aik@...abs.ru,
	david@...son.dropbear.id.au, joerg.roedel@....com,
	dwmw2@...radead.org, chrisw@...s-sol.org, agraf@...e.de,
	benve@...co.com, aafabbri@...co.com, B08248@...escale.com,
	B07421@...escale.com, avi@...hat.com, konrad.wilk@...cle.com,
	kvm@...r.kernel.org, qemu-devel@...gnu.org,
	iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
	bhelgaas@...gle.com
Subject: Re: [PATCH v2 09/13] vfio: x86 IOMMU implementation

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<alex.williamson@...hat.com>
>>> ---
>>>
>>>    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
>>>    					<mailto:mcr@...idum.com>
>>> -';'	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<other-arch>  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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/