Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling

On Sat, Jun 22, 2013 at 08:28:06AM -0600, Alex Williamson wrote:

On Sat, 2013-06-22 at 22:03 +1000, David Gibson wrote:

quoted

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

quoted

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.

While the container is the gateway to the iommu, what empowers the
container to maintain an iommu is the group.  What happens to a
container when all the groups are disconnected or closed?  Groups are
the unit that indicates hardware access, not containers.  Thanks,

Uh... huh?  I'm really not sure what you're getting at.

The operation we're doing for KVM here is binding a guest iommu
address space to a particular host iommu address space.  Why would we
not want to use the obvious handle on the host iommu address space,
which is the container fd?

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