linux-kernel - Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Jun 2010 16:06:21 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Joerg Roedel <joro@...tes.org>
CC:	"Michael S. Tsirkin" <mst@...hat.com>, Tom Lyon <pugs@...co.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	chrisw@...s-sol.org, hjk@...utronix.de, gregkh@...e.de,
	aafabbri@...co.com, scofeldm@...co.com
Subject: Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

On 06/02/2010 03:50 PM, Joerg Roedel wrote:
>
>> The problem with this is that it is assymetric, dev1 is treated
>> differently from dev[234].  It's an unintuitive API.
>>      
> Its by far more unintuitive that a process needs to explicitly bind a
> device to an iommu domain before it can do anything with it.

I don't really care about the iommu domain.  It's a side effect.  The 
kernel takes care of it.  I'm only worried about the API.

We have a memory map that is (often) the same for a set of devices.  If 
you were coding a non-kernel interface, how would you code it?

   struct memory_map;
   void memory_map_init(struct memory_map *mm, ...);
   struct device;
   void device_set_memory_map(struct device *device, struct memory_map *mm);

or

   struct device;
   void device_init_memory_map(struct device *dev, ...);
   void device_clone_memory_map(struct device *dev, struct device *other);

I wouldn't even think of the second one personally.

> If its
> required anyway the binding can happen implicitly. We could allow to do
> a nop 'ioctl(dev1, SHARE, dev1)' to remove the asymmetry.
>    

It's still special.  You define the memory map only for the first 
device.  You have to make sure dev1 doesn't go away while sharing it.

> Note that this way of handling userspace iommu mappings is also a lot
> simpler for most use-cases outside of KVM. If a developer wants to write
> a userspace driver all it needs to do is:
>
> dev = open();
> ioctl(dev, MAP, ...);
> /* use device with mappings */
> close(dev);
>
> Which is much easier than the need to create a domain explicitly.
>    

mm = open()
ioctl(mm, MAP, ...)
dev = open();
ioctl(dev, BIND, mm);
...
close(mm);
close(dev);

so yes, more work, but once you have multiple devices which come and go 
dynamically things become simpler.  The map object has global lifetime 
(you can even construct it if you don't assign any devices), the devices 
attach to it, memory hotplug updates the memory map but doesn't touch 
devices.

-- 
error compiling committee.c: too many arguments to function

--
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/