RE: [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s

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

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Saturday, April 16, 2022 9:33 AM
> 
> On Sat, Apr 16, 2022 at 12:00:12AM +0000, Tian, Kevin wrote:
> > You probably remember there is one additional requirement when
> > adding ENQCMD virtualization on Intel platform. KVM is required to
> > setup a guest PASID to host PASID translation table in CPU vmcs
> > structure to support ENQCMD in the guest. Following above direction
> > I suppose KVM will provide a new interface to allow user pass in
> >  [devfd, iommufd, guest_pasid] and then call a new vfio ops e.g.
> > vfio_file_translate_guest_pasid(dev_file, iommufd, gpasid) to
> > retrieve the host pasid. This sounds correct in concept as iommufd
> > only knows host pasid and any g->h information is managed by
> > vfio device driver.
> 
> I think there is no direct linkage of KVM to iommufd or VFIO for
> ENQCMD.
> 
> The security nature of KVM is that the VM world should never have more
> privilege than the hypervisor process running the KVM.

Indeed.

> 
> Therefore, when VM does a vENQCMD it must be equviliant to a physical
> ENQCMD that the KVM process could already execute anyhow. Yes, Intel
> wired ENQCMD to a single PASID, but we could imagine a system call
> that allowed the process to change the PASID that ENQCMD uses from an
> authorized list of PASIDs that the process has access to.

Yes, this makes more sense in concept. Just one note that for vENQCMD
guest changes PASID via xsave/xrstor which is not trapped thus we don't
need such change-PASID syscall in practice. The kernel just need maintain
a list of authorized PASIDs and setup the PASID translation structure 
properly in CPU. Then the guest is allowed to access any PASID authorized
and translated by the CPU. 

> 
> So, the linkage from iommufd is indirect. When iommufd does whatever
> to install a PASID in the process's ENQCMD authorization table KVM can
> be instructed to link that PASID inside the ENQCMD to a vPASID in the
> VM.
> 
> As long as the PASID is in the process table KVM can allow the VM to
> use it.
> 
> And it explains how userspace can actually use ENQCMD in a VFIO
> scenario with iommufd, where obviously it needs to be in direct
> control of what PASID ENQCMD generates and not be tied only to the
> PASID associated with the mm_struct.
> 

This reminds me back to the previous ioasid_set concept introduced
by Jacob [1]. Let's ignore the implementation detail for a while as lots
of logic there don't hold now given the progress of iommufd. But just
very high level concept-wise:

- Each mm is associated with a set of authorized PASIDs (ioasid_set);
- VFIO driver provides a uAPI for userspace to attach a guest virtual
  PASID (vPASID) to a hw page table in iommufd. In the uAPI:
    - a physical PASID (pPASID) is allocated and added to mm's ioasid_set;
    - the pPASID is used to actually attach to the hw page table;
    - the pPASID is returned to userspace upon successful attach;
- KVM provides a uAPI for userspace to map/unmap vPASID to pPASID
  in CPU PASID translation structure. User-provided pPASID must be
  found in mm->ioasid_set;

In this case the linkage from vfio/iommufd does be indirect.

My earlier reply was probably based on a wrong memory that the
entire ioasid_set concept was killed when the lengthy discussion
in [1] led to the debut of iommufd.

Thanks
Kevin

[1] https://lore.kernel.org/all/1614463286-97618-1-git-send-email-jacob.jun.pan@linux.intel.com/