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

[Tom Lyon <pugs@lyon-about.com>]

On Tuesday 01 June 2010 09:29:47 pm Alex Williamson wrote:
> On Tue, 2010-06-01 at 13:28 +0300, Avi Kivity wrote:
> > On 06/01/2010 12:55 PM, Michael S. Tsirkin wrote:
> > >
> > >>   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.
> > >    
> > 
> >    iommufd = open(/dev/iommu);
> >    ioctl(iommufd, IOMMUFD_ASSIGN_RANGE, ...)
> >    ioctl(vfiofd, VFIO_SET_IOMMU, iommufd)
> 
> It seems part of the annoyance of the current KVM device assignment is
> that we have multiple files open, we mmap here, read there, write over
> there, maybe, if it's not emulated.  I quite like Tom's approach that we
> have one stop shopping with /dev/vfio<n>, including config space
> emulation so each driver doesn't have to try to write their own.  So
> continuing with that, shouldn't we be able to add a GET_IOMMU/SET_IOMMU
> ioctl to vfio so that after we setup one device we can bind the next to
> the same domain?

This is just what I was thinking.  But rather than a get/set, just use two fds.

	ioctl(vfio_fd1, VFIO_SET_DOMAIN, vfio_fd2);

This may fail if there are really 2 different IOMMUs, so user code must be
prepared for failure,  In addition, this is strictlyupwards compatible with 
what is there now, so maybe we can add it later.