lkml.org 
[lkml]   [2010]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] VFIO driver: Non-privileged user level PCI drivers
Date
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.




\
 
 \ /
  Last update: 2010-06-02 07:05    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean