On Sat, 2013-06-22 at 22:03 +1000, David Gibson wrote: > 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: > > > On 06/20/2013 05:47 PM, Benjamin Herrenschmidt wrote: > > > > On Thu, 2013-06-20 at 15:28 +1000, David Gibson wrote: > > > >>> Just out of curiosity - would not get_file() and fput_atomic() on a > > > >> group's > > > >>> 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, Alex -- 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
