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. -- 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
