On Tue, Aug 09, 2016 at 06:16:30AM -0600, Alex Williamson wrote: > On Tue, 9 Aug 2016 15:19:39 +1000 > Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > > > On 09/08/16 02:43, Alex Williamson wrote: > > > > > > I think you need to take a closer look of the lifecycle of a container, > > > having a reference means the container itself won't go away, but only > > > having a group set within that container holds the actual IOMMU > > > references. container->iommu_data is going to be NULL once the > > > groups are lost. Thanks, > > > > > > Container owns the iommu tables and this is what I care about here, groups > > attached or not - this is handled separately via IOMMU group list in a > > specific iommu_table struct, these groups get detached from iommu_table > > when they are removed from a container. > > The container doesn't own anything, the container is privileged by the > groups being attached to it. When groups are closed, they detach from > the container and once the container group list is empty the iommu > backend is released and iommu_data is NULL. A container reference > doesn't give you what you're looking for. It implies nothing about the > iommu backend.
Alex, I'd like to understand more what the objection is here - is it just about the object lifetimes, or is it a more fundamental objection to the style of interface? Regarding lifetimes, my understanding was that Alexey's previous patches added refcounting to the iommu tables, so that KVM could get a reference to the iommu tables through the container and then safely use the iommu tables directly. There may still be a potential race in the interval between asking the container about its iommu tables and incrementing the tables' reference counts, but that should be able to be solved. I don't see any unsolvable problem regarding lifetimes. Or is your objection about any external access to the container? As far as I know, when a group is not part of a container it has its own iommu tables, but when it is put in a container it loses its own iommu tables and instead uses a common pair of iommu tables (one for the 32-bit window, one for the 64-bit window) that belong to the container. So we do in fact need the container's iommu tables not the individual groups' tables. Regards, Paul.