On Thu, Dec 02, 2021 at 03:23:38PM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 02, 2021 at 09:55:02AM -0400, Jason Gunthorpe wrote: > > Further, there is no reason why IMS should be reserved exclusively for > > VFIO! Why shouldn't the cdev be able to use IMS vectors too? It is > > just a feature of the PCI device like MSI. If the queue has a PASID it > > can use IDXD's IMS. > > No, sorry, but a cdev is not for anything resembling any real resource > at all. My point is that when the user asks the driver to allocate a queue through a cdev ioctl it should be able to get the queue attached to an IMS, today it can only get a queue attached to a MSI. > It is ONLY for the /dev/NODE interface that controls the character > device api to userspace. The struct device involved in it is ONLY for > that, nothing else. Any attempt to add things to it will be gleefully > rejected. I agree with you! > > If we really need a 2nd struct device to turn on IMS then, I'd suggest > > picking the cdev, as it keeps IMS and its allocator inside the IDXD > > PCIe driver and not in the VFIO world. > > No! Again, a cdev is to control the lifespan/lifecycle of the /dev/NODE > only. Anything other than that is not ok to do at all. Said the same thing in a prior email - which is why I think the only logical choice here is to make IMS work on the pci_device FWIW I feel the same way about the VFIO mdev - its *ONLY* purpose is to control the lifecycle and we are close to stripping away all the other abuses using it for other things. Jason
