On Wed, May 05, 2021 at 10:22:59AM -0700, Jacob Pan wrote: > Global and pluggable are for slightly separate reasons. > - We need global PASID on VT-d in that we need to support shared > workqueues (SWQ). E.g. One SWQ can be wrapped into two mdevs then assigned > to two VMs. Each VM uses its private guest PASID to submit work but > each guest PASID must be translated to a global (system-wide) host PASID to > avoid conflict. Also, since PASID table storage is per PF, if two mdevs of > the same PF are assigned to different VMs, the PASIDs must be unique. >From a protocol perspective each RID has a unique PASID table, and RIDs can have overlapping PASIDs. Since your SWQ is connected to a single RID the requirement that PASIDs are unique to the RID ensures they are sufficiently unique. If the IOMMU driver has additional restrictions then it should raise the PASID table up higher in the hierarchy than at the RID. I think what you are trying to explain is that the Intel vIOMMU has a single PASID address space shared globally by the vCPU because ENQCMD uses the global vGPU translation table. That is fine, but all this stuff should be inside the Intel vIOMMU driver not made into a global resource of the entire iommu subsystem. Systems that work this way just cannot have multiple iommu drivers competing for PASID. > - The pluggable allocator is to support the option where the guest PASIDs > are allocated by the hypervisor. And if the hypervisor allocates the PASID then again the specific vIOMMU itself is concerned with this and it has nothing to do with global behavior of the iommu subsystem. > For ARM, since the guest owns the per device PASID table. There is no need > to allocate PASIDs from the host nor the hypervisor. Without SWQ, there is > no need for global PASID/SSID either. So PASID being global for ARM is for > simplicity in case of host PASID/SSID. It isn't clear how ARM can support PASID and mdev but that is an unrelated issue.. Jason
