On Tue, 11 Apr 2023 10:24:58 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Thu, Apr 06, 2023 at 11:53:47AM -0600, Alex Williamson wrote: > > > Where whether a device is opened is subject to change outside of the > > user's control. This essentially allows the user to perform hot-resets > > of devices outside of their ownership so long as the device is not > > used elsewhere, versus the current requirement that the user own all the > > affected groups, which implies device ownership. It's not been > > justified why this feature needs to exist, imo. > > The cdev API doesn't have the notion that owning a group means you > "own" some collection of devices. It still happens as a side effect, > but it isn't obviously part of the API. I'm really loath to > re-introduce that group-based concept just for this. We are trying > reduce the group API surface. > > How about a different direction. > > We add a new uAPI for cdev mode that is "take ownership of the reset > group". Maybe it can be a flag in during bind. > > When requested vfio will ensure that every device in the reset group > is only bound to this iommufd_ctx or left closed. Now and in the > future. Since no-iommu has no iommufd_ctx this means we can open only > one device in the reset group. > > With this flag RESET is guaranteed to always work by definition. > > We continue with the zero-length FD, but we can just replace the > security checks with a check if we are in reset group ownership mode. > > _INFO is unchanged. > > We decide if we add a new IOCTL to return the BDF so the existing > _INFO can get back to the dev_id or a new IOCTL that returns the > dev_id list of the reset group. > > Userspace is required to figure out the extent of the reset, but we > don't require that userspace prove to the kernel it did this when > requesting the reset. Take for example a multi-function PCIe device with ACS isolation between functions, are you going to allow a user who has only been granted ownership of a subset of functions control of the entire dev_set? It seems this proposal essentially extends the ownership model to the greater of the dev_set or iommu group, apparently neither of which are explicitly exposed to the user in the cdev API. How does a user determine when devices cannot be used independently in the cdev API? Thanks, Alex
