On Wed, Jun 02, 2010 at 12:19:40PM +0200, Joerg Roedel wrote: > On Wed, Jun 02, 2010 at 12:53:12PM +0300, Michael S. Tsirkin wrote: > > On Wed, Jun 02, 2010 at 11:42:01AM +0200, Joerg Roedel wrote: > > > > IMO a seperate iommu-userspace driver is a nightmare for a userspace > > > interface. It is just too complicated to use. > > > > One advantage would be that we can reuse the uio framework > > for the devices themselves. So an existing app can just program > > an iommu for DMA and keep using uio for interrupts and access. > > The driver is called UIO and not U-INTR-MMIO ;-) So I think handling > IOMMU mappings belongs there. > > > > We can solve the problem > > > of multiple devices-per-domain with an ioctl which allows binding one > > > uio-device to the address-space on another. > > > > This would imply switching an iommu domain for a device while > > it could potentially be doing DMA. No idea whether this can be done > > in a safe manner. > > It can. The worst thing that can happen is an io-page-fault. devices might not be able to recover from this. > > Forcing iommu assignment to be done as a first step seems much saner. > > If we force it, there is no reason why not doing it implicitly. What you describe below does 3 ioctls for what can be done with 1. > We can do something like this then: > > dev1 = open(); > ioctl(dev1, IOMMU_MAP, ...); /* creates IOMMU domain and assigns dev1 to > it*/ > > dev2 = open(); > ioctl(dev2, IOMMU_MAP, ...); > > /* Now dev1 and dev2 are in seperate domains */ > > ioctl(dev2, IOMMU_SHARE, dev1); /* destroys all mapping for dev2 and > assigns it to the same domain as > dev1. Domain has a refcount of two > now */ Or maybe it destroys mapping for dev1? How do you remember? > close(dev1); /* domain refcount goes down to one */ > close(dev2); /* domain refcount is zero and domain gets destroyed */ > > > Joerg Also, no way to unshare? That seems limiting. -- MST -- 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
