On Tue, 2013-06-18 at 14:38 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2013-06-17 at 20:32 -0600, Alex Williamson wrote: > > > Right, we don't want to create dependencies across modules. I don't > > have a vision for how this should work. This is effectively a complete > > side-band to vfio, so we're really just dealing in the iommu group > > space. Maybe there needs to be some kind of registration of ownership > > for the group using some kind of token. It would need to include some > > kind of notification when that ownership ends. That might also be a > > convenient tag to toggle driver probing off for devices in the group. > > Other ideas? Thanks, > > All of that smells nasty like it will need a pile of bloody > infrastructure.... which makes me think it's too complicated and not the > right approach. > > How does access control work today on x86/VFIO ? Can you give me a bit > more details ? I didn't get a good grasp in your previous email.... The current model is not x86 specific, but it only covers doing iommu and device access through vfio. The kink here is that we're trying to do device access and setup through vfio, but iommu manipulation through kvm. We may want to revisit whether we can do the in-kernel iommu manipulation through vfio rather than kvm. For vfio in general, the group is the unit of ownership. A user is granted access to /dev/vfio/$GROUP through file permissions. The user opens the group and a container (/dev/vfio/vfio) and calls SET_CONTAINER on the group. If supported by the platform, multiple groups can be set to the same container, which allows for iommu domain sharing. Once a group is associated with a container, an iommu backend can be initialized for the container. Only then can a device be accessed through the group. So even if we were to pass a vfio group file descriptor into kvm and it matched as some kind of ownership token on the iommu group, it's not clear that's sufficient to assume we can start programming the iommu. Thanks, Alex > From the look of it, the VFIO file descriptor is what has the "access > control" to the underlying iommu, is this right ? So we somewhat need to > transfer (or copy) that ownership from the VFIO fd to the KVM VM. > > I don't see a way to do that without some cross-layering here... > > Rusty, are you aware of some kernel mechanism we can use for that ? > > Cheers, > Ben. > > -- 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
