Messages in this thread | | | Date | Tue, 1 Jun 2010 13:46:51 +0300 | From | "Michael S. Tsirkin" <> | Subject | Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers |
| |
On Tue, Jun 01, 2010 at 01:28:48PM +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) > > ?
Yes.
> If so, I agree.
Good.
>> 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. >> > > Since vfio would be the only driver, there would be no duplication. But > a separate object for the iommu mapping is a good thing. Perhaps we can > even share it with vhost (without actually using the mmu, since vhost is > software only).
Main difference is that vhost works fine with unlocked memory, paging it in on demand. iommu needs to unmap memory when it is swapped out or relocated.
> -- > error compiling committee.c: too many arguments to function
| |