On Wed, Jun 02, 2010 at 04:17:19PM +0300, Michael S. Tsirkin wrote: > On Wed, Jun 02, 2010 at 02:50:50PM +0200, Joerg Roedel wrote: > > On Wed, Jun 02, 2010 at 03:25:11PM +0300, Avi Kivity wrote: > > > On 06/02/2010 03:19 PM, Joerg Roedel wrote: > > > If its > > required anyway the binding can happen implicitly. We could allow to do > > a nop 'ioctl(dev1, SHARE, dev1)' to remove the asymmetry. > > And then when we assign meaning to it we find that half the apps > are broken because they did not call this ioctl. The meaning is already assigned and chaning it means changing the userspace-abi which is a no-go. > This simple scenario ignores all the real-life corner cases. > For example, with an explicit iommu open and bind application > can naturally detect that: > - we have run out of iommu domains ioctl(dev, MAP, ...) will fail in this case. > - iommu is unsupported Is best checked by open() anyway because userspace can't do anything with the device before it is bound to a domain. > - iommu is in use by another, incompatible device How should this happen? > - device is in bad state How is this checked with your proposal and why can this not be detected with my one? > because each is a separate operation, so it is easy to produce meaningful > errors. Ok, this is true. > Another interesting thing that a separate iommu device supports is when > application A controls the iommu and application B > controls the device. Until Linux becomes a micro-kernel the IOMMU itself will _never_ be controlled by an application. > This might be good to e.g. improve security (B is run by root, A is > unpriveledged and passes commands to/from B over a pipe). Micro-kernel arguments. I hope a userspace controlled IOMMU in Linux will never happen ;-) Joerg -- 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
