On Tue, May 11, 2021 at 02:56:05PM +0800, Lu Baolu wrote: > > After my next series the mdev drivers will have direct access to > > the vfio_device. So an alternative to using the struct device, or > > adding 'if mdev' is to add an API to the vfio_device world to > > inject what iommu configuration is needed from that direction > > instead of trying to discover it from a struct device. > > Just want to make sure that I understand you correctly. > > We should use the existing IOMMU in-kernel APIs to connect mdev with the > iommu subsystem, so that the upper lays don't need to use something > like (if dev_is_mdev) to handle mdev differently. Do I get you > correctly? After going through all the /dev/ioasid stuff I'm pretty convinced that none of the PASID use cases for mdev should need any iommu connection from the mdev_device - this is an artifact of trying to cram the vfio container and group model into the mdev world and is not good design. The PASID interfaces for /dev/ioasid should use the 'struct pci_device' for everything and never pass in a mdev_device to the iommu layer. /dev/ioasid should be designed to support this operation and is why I strongly want to see the actual vfio_device implementation handle the connection to the iommu layer and not keep trying to hack through building what is actually a vfio_device specific connection through the type1 container code. > > 3) The vfio_bus_is_mdev() and related symbol_get() nonsense in > > drivers/vfio/vfio_iommu_type1.c has to go, for the same reasons > > it was not acceptable to do this for the interrupt side either. > > Yes. Agreed. I will look into it. This will be harder, but the same logic applies - it serves to allow controlling an ioasid without involving the vfio_device. Jason
