RE: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

["Tian, Kevin" <kevin.tian@intel.com>]

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Monday, September 27, 2021 10:40 PM
> 
> On Mon, Sep 27, 2021 at 01:32:34PM +0000, Tian, Kevin wrote:
> 
> > but I'm little worried that even vfio-pci itself cannot be bound now,
> > which implies that all devices in a group which are intended to be
> > used by the user must be bound to vfio-pci in a breath before the
> > user attempts to open any of them, i.e. late-binding and device-
> > hotplug is disallowed after the initial open. I'm not sure how
> > important such an usage would be, but it does cause user-tangible
> > semantics change.
> 
> Oh, that's bad..
> 
> I guess your approach is the only way forward, it will have to be
> extensively justified in the commit message for Greg et al.
> 

Just thought about another alternative. What about having driver
core to call iommu after call_driver_probe()?

call_driver_probe()
	pci_stub_probe()
		iommu_set_dma_mode(dev, DMA_NONE);
iommu_check_dma_mode(dev);

The default dma mode is DMA_KERNEL. Above allows driver to opt
for DMA_NONE or DMA_USER w/o changing the device_driver
structure. Right after probe() is completed, we check whether dma 
mode of this device is allowed by the iommu core (based on recorded 
dma mode info of sibling devices in the same group). If not, then fail 
the binding.

Thanks
Kevin