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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
