On Wed, Apr 17, 2024 at 05:02:16PM -0600, Alex Williamson wrote: > > > sure but we at least need to reach consensus on a minimal required > > > uapi covering both PF/VF to move forward so the user doesn't need > > > to touch different contracts for PF vs. VF. > > > > Do we? The situation where the VMM needs to wholly make a up a PASID > > capability seems completely new and seperate from just using an > > existing PASID capability as in the PF case. > > But we don't actually expose the PASID capability on the PF and as > argued in path 4/ we can't because it would break existing > userspace. Are we sure about that argument? Exposing the PF's PASID cap to qemu shouldn't break qemu at all - it will just pass it over into a vPCI function? Ultimately the guest will observe a vPCI device with a PASID cap. This is not really so different from plugging in a new PCI device with the PASID cap into an old HW system that doesn't support PASID. So does a guest break? I'd expect no - the viommu's created by qemu should not advertise PASID support already. So the guest can't use PASID - just like an old HW system. Is there a known concrete thing that breaks there? > > If it needs to make another system call or otherwise to do that then > > that seems fine to do incrementally?? > > With PASID currently hidden, VF and PF support really seem too similar > not to handle them both at the same time. What's missing is a > mechanism to describe unused config space where userspace can implement > an emulated PASID capability. Yes, sure the unused config space is a great idea. I thought we were talking about doing the fixup in userspace, but a kernel solution is good too. But also if we are set on the dvsec, in kernel or user, then we can move ahead with the core PASID enablement immediately? Jason
