On Fri, Apr 23, 2021 at 10:38:51AM -0600, Alex Williamson wrote: > On Thu, 22 Apr 2021 20:39:50 -0300 > > /dev/ioasid should understand the group concept somehow, otherwise it > > is incomplete and maybe even security broken. > > > > So, how do I add groups to, say, VDPA in a way that makes sense? The > > only answer I come to is broadly what I outlined here - make > > /dev/ioasid do all the group operations, and do them when we enjoin > > the VDPA device to the ioasid. > > > > Once I have solved all the groups problems with the non-VFIO users, > > then where does that leave VFIO? Why does VFIO need a group FD if > > everyone else doesn't? > > This assumes there's a solution for vDPA that doesn't just ignore the > problem and hope for the best. I can't speak to a vDPA solution. I don't think we can just ignore the question and succeed with /dev/ioasid. Guess it should get answered as best it can for ioasid "in general" then we can decide if it makes sense for VFIO to use the group FD or not when working in ioasid mode. Maybe a better idea will come up > an implicit restriction. You've listed a step in the description about > a "list of devices in the group", but nothing in the pseudo code > reflects that step. I gave it below with the readdir() - it isn't in the pseudo code because the applications I looked through didn't use it, and wouldn't benefit from it. I tried to show what things were doing today. > I expect it would be a subtly missed by any userspace driver > developer unless they happen to work on a system where the grouping > is not ideal. I'm still unclear - what are be the consequence if the application designer misses the group detail? Jason
