On 27/09/2018 04:22, Liu, Yi L wrote: >> For the "classic" vfio-pci case, "SVA in guest" still means giving the >> guest control over the whole PASID table. > > No, if giving guest control over the whole PASID table, it means guest may > have > its own PASID namespace. right? And for vfio-mdev case, it gets PASID from > host. > So there would be multiple PASID namespaces. Thinking about the following > scenario: > > A PF/VF assigned to a VM via "classic" vfio-pci. And an > assignable-device-interface > assigned to this VM via vfio-mdev. If an application in this VM tries to > manipulate > these two "devices", it should have the same PASID programmed to them. right? > But as the above comments mentioned, for vfio-pci case, it would get a PASID > from > its own PASID namespace. While the vfio-mdev case would get a PASID from host. > This would result in conflict.
Ah I see, if the host assigns an ADI via vfio-mdev and a PCI function via vfio-pci to the same VM, the guest needs to use the paravirtualized PASID allocator for the PCI device as well, not just the ADI. In fact all guest PASIDs need to be allocated through one PV channel, even if the VM has other vIOMMUs that don't support PV. But I suppose that kind of VM is unrealistic. However for SMMUv3 we'll still use the bind_pasid_table for vfio-pci and let the guest allocate PASIDs, since the PASID table lives in guest-physical space. In any case, for the patch series at hand, it means that iommu-sva will need assistance from the vt-d driver to allocate PASIDs: host uses the generic allocator, guest uses the PV one. I guess the mm_alloc() op could do that? Thanks, Jean _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
