> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, November 17, 2020 2:03 AM > > On Mon, Nov 16, 2020 at 06:56:33PM +0100, Thomas Gleixner wrote: > > On Mon, Nov 16 2020 at 11:46, Jason Gunthorpe wrote: > > > > > On Mon, Nov 16, 2020 at 07:31:49AM +0000, Tian, Kevin wrote: > > > > > >> > The subdevices require PASID & IOMMU in native, but inside the guest > there > > >> > is no > > >> > need for IOMMU unless you want to build SVM on top. subdevices > work > > >> > without > > >> > any vIOMMU or hypercall in the guest. Only because they look like > normal > > >> > PCI devices we could map interrupts to legacy MSIx. > > >> > > >> Guest managed subdevices on PF/VF requires vIOMMU. > > > > > > Why? I've never heard we need vIOMMU for our existing SRIOV flows in > > > VMs?? > > > > Handing PF/VF into the guest does not require it. > > > > But if the PF/VF driver in the guest wants to create and manage the > > magic mdev subdevices which require PASID support then you surely need > > it. > > 'magic mdevs' are only one reason to use IMS in a guest. On mlx5 we > might want to use IMS for VPDA devices. mlx5 can spawn a VDPA device > in a guest, against a 'ADI', without ever requiring an IOMMU to do it. > > We don't even need IOMMU in the hypervisor to create the ADI, mlx5 has > an internal secure IOMMU that can be used instead of the platform > IOMMU. > > Not saying this is a major use case, or a reason not to link things to > IOMMU detection, but lets be clear that a hard need for IOMMU is a > another IDXD thing, not general. > I should use "may require" in original post. and one thing that I obviously mixed is the requirement of PASID-granular interrupt isolation in the physical IOMMU instead of virtual IOMMU. But anyway, I didn't attempt to use above to build hard need for IOMMU, just the opposite when looking at all three cases together. btw Jason/Thomas, how do you think about the proposal down in this thread (ims=[auto|on|off])? Does it sound a good tradeoff to move forward? Thanks Kevin
