Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 02, 2010 at 12:35:16PM +0200, Joerg Roedel wrote:
> On Wed, Jun 02, 2010 at 01:21:44PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 02, 2010 at 12:19:40PM +0200, Joerg Roedel wrote:
> 
> > > It can. The worst thing that can happen is an io-page-fault.
> > 
> > devices might not be able to recover from this.
> 
> With the userspace interface a process can create io-page-faults
> anyway if it wants. We can't protect us from this.

We could fail all operations until an iommu is bound.
This will help catch bugs with access before setup. We can not do this
if a domain is bound by default.

> And the process is
> also responsible to not tear down iommu-mappings that are currently in
> use.
> 
> > What you describe below does 3 ioctls for what can be done with 1.
> 
> The second IOMMU_MAP ioctl is just to show that existing mappings would
> be destroyed if the device is assigned to another address space. Not
> strictly necessary. So we have two ioctls but save one call to create
> the iommu-domain.

With 10 devices you have 10 extra ioctls.

> > > 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?
> 
> Because we express here that "dev2 shares the iommu mappings of dev1".
> Thats easy to remember.

they both share the mappings. which one gets the iommu
destroyed (breaking the device if it is now doing DMA)?

> > Also, no way to unshare? That seems limiting.
> 
> Just left out for simplicity reasons. An IOMMU_UNBIND (no IOMMU_UNSHARE
> because that would require a second parameter) ioctl is certainly also
> required.
> 
> 	Joerg



-- 
MST