On Thu, Jun 20, 2013 at 08:55:13AM -0600, Alex Williamson wrote:

On Thu, 2013-06-20 at 18:48 +1000, Alexey Kardashevskiy wrote:

quoted

On 06/20/2013 05:47 PM, Benjamin Herrenschmidt wrote:

quoted

On Thu, 2013-06-20 at 15:28 +1000, David Gibson wrote:

quoted

quoted

Just out of curiosity - would not get_file() and fput_atomic() on a

group's

quoted

file* do the right job instead of vfio_group_add_external_user() and
vfio_group_del_external_user()?

I was thinking that too.  Grabbing a file reference would certainly be
the usual way of handling this sort of thing.

But that wouldn't prevent the group ownership to be returned to
the kernel or another user would it ?

Holding the file pointer does not let the group->container_users counter go
to zero

How so?  Holding the file pointer means the file won't go away, which
means the group release function won't be called.  That means the group
won't go away, but that doesn't mean it's attached to an IOMMU.  A user
could call UNSET_CONTAINER.

Uhh... *thinks*.  Ah, I see.

I think the interface should not take the group fd, but the container
fd.  Holding a reference to *that* would keep the necessary things
around.  But more to the point, it's the right thing semantically:

The container is essentially the handle on a host iommu address space,
and so that's what should be bound by the KVM call to a particular
guest iommu address space.  e.g. it would make no sense to bind two
different groups to different guest iommu address spaces, if they were
in the same container - the guest thinks they are different spaces,
but if they're in the same container they must be the same space.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson