On Wed, Apr 24, 2024 at 12:24:37PM -0600, Alex Williamson wrote: > > The only reason to pass the PF's PASID cap is to give free space to > > the VMM. If we are saying that gaps are free space (excluding a list > > of bad devices) then we don't acutally need to do that anymore. > > Are we saying that now?? That's new. I suggested it a few times > > > VMM will always create a synthetic PASID cap and kernel will always > > suppress a real one. > > > > An iommufd query will indicate if the vIOMMU can support vPASID on > > that device. > > > > Same for all the troublesome non-physical caps. > > > > > > There are migration considerations too - the blocks need to be > > > > migrated over and end up in the same place as well.. > > > > > > Can you elaborate what is the problem with the kernel emulating > > > the PASID cap in this consideration? > > > > If the kernel changes the algorithm, say it wants to do PASID, PRI, > > something_new then it might change the layout > > > > We can't just have the kernel decide without also providing a way for > > userspace to say what the right layout actually is. :\ > > The capability layout is only relevant to migration, right? Yes, proabbly > A variant > driver that supports migration is a prerequisite and would also be > responsible for exposing the PASID capability. This isn't as disjoint > as it's being portrayed. I guess.. But also not quite. We still have the problem that kernel migration driver V1 could legitimately create a different config space that migration driver V2 And now you are saying that the migration driver has to parse the migration stream and readjust its own layout And every driver needs to do this? We can, it is a quite big bit of infrastructure I think, but sure.. I fear the VMM still has to be involved somehow because it still has to know if the source VMM has removed any kernel created caps. > Outside of migration, what does it matter if the cap layout is > different? A driver should never hard code the address for a > capability. Yes, talking about migration here - migration is the hardest case it seems. > > At least if the VMM is doing this then the VMM can include the > > information in its migration scheme and use it to recreate the PCI > > layout withotu having to create a bunch of uAPI to do so. > > We're again back to migration compatibility, where again the capability > layout would be governed by the migration support in the in-kernel > variant driver. Once migration is involved the location of a PASID > shouldn't be arbitrary, whether it's provided by the kernel or the VMM. I wasn't going in this direction. I was thinking to make the VMM create the config space layout that is approriate and hold it stable as a migration ABI. I think in practice many VMMs are going to do this anyhow unless we put full support for config space synthesis, stable versions, and version selection in the kernel directly. I was thinking to avoid doing that. > Regardless, the VMM ultimately has the authority what the guest > sees in config space. The VMM is not bound to expose the PASID at the > offset provided by the kernel, or bound to expose it at all. The > kernel exposed PASID can simply provide an available location and set > of enabled capabilities. And if the VMM is going to ignore the kernel layout then why do so much work in the kernel to create it? I think we need to decide, either only the VMM or only the kernel should do this. Jason
