> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx/
