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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jun 01, 2010 at 11:10:45AM +0300, Avi Kivity wrote:
> On 05/31/2010 08:10 PM, Michael S. Tsirkin wrote:
>> On Mon, May 31, 2010 at 02:50:29PM +0300, Avi Kivity wrote:
>>    
>>> On 05/30/2010 05:53 PM, Michael S. Tsirkin wrote:
>>>      
>>>> So what I suggested is failing any kind of access until iommu
>>>> is assigned.
>>>>
>>>>        
>>> So, the kernel driver must be aware of the iommu.  In which case it may
>>> as well program it.
>>>      
>> It's a kernel driver anyway. Point is that
>> the *device* driver is better off not programming iommu,
>> this way we do not need to reprogram it for each device.
>>    
>
> The device driver is in userspace.

I mean the kernel driver that grants userspace the access.

>  It can't program the iommu.
> What  
> the patch proposes is that userspace tells vfio about the needed  
> mappings, and vfio programs the iommu.

There seems to be some misunderstanding.  The userspace interface
proposed forces a separate domain per device and forces userspace to
repeat iommu programming for each device.  We are better off sharing a
domain between devices and programming the iommu once.

The natural way to do this is to have an iommu driver for programming
iommu.

This likely means we will have to pass the domain to 'vfio' or uio or
whatever the driver that gives userspace the access to device is called,
but this is only for security, there's no need to support programming
iommu there.

And using this design means the uio framework changes
required would be minor, so we won't have to duplicate code.

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