On Wed, Nov 20, 2019 at 10:28:56AM -0700, Alex Williamson wrote: > > > Are you objecting the mdev_set_iommu_deivce() stuffs here? > > > > I'm questioning if it fits the vfio PCI device security model, yes. > > The mdev IOMMU backing device model is for when an mdev device has > IOMMU based isolation, either via the PCI requester ID or via requester > ID + PASID. For example, an SR-IOV VF may be used by a vendor to > provide IOMMU based translation and isolation, but the VF may not be > complete otherwise to provide a self contained device. It might > require explicit coordination and interaction with the PF driver, ie. > mediation. In this case the PF does not look to be involved, the ICF kernel driver is only manipulating registers in the same VF that the vfio owns the IOMMU for. This is why I keep calling it a "so-called mediated device" because it is absolutely not clear what the kernel driver is mediating. Nearly all its work is providing a subsystem-style IOCTL interface under the existing vfio multiplexer unrelated to vfio requirements for DMA. > The IOMMU backing device is certainly not meant to share an IOMMU > address space with host drivers, except as necessary for the > mediation of the device. The vfio model manages the IOMMU domain of > the backing device exclusively, any attempt to dual-host the device > respective to the IOMMU should fault in the dma/iommu-ops. Thanks, Sounds more reasonable if the kernel dma_ops are prevented while vfio is using the device. However, to me it feels wrong that just because a driver wishes to use PASID or IOMMU features it should go through vfio and mediated devices. It is not even necessary as we have several examples already of drivers using these features without vfio. I feel like mdev is suffering from mission creep. I see people proposing to use mdev for many wild things, the Mellanox SF stuff in the other thread and this 'virtio subsystem' being the two that have come up publicly this month. Putting some boundaries on mdev usage would really help people know when to use it. My top two from this discussion would be: - mdev devices should only bind to vfio. It is not a general kernel driver matcher mechanism. It is not 'virtual-bus'. - mdev & vfio are not a substitute for a proper kernel subsystem. We shouldn't export a complex subsystem-like ioctl API through vfio ioctl extensions. Make a proper subsystem, it is not so hard. Maybe others agree? Thanks, Jason
