> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Saturday, July 17, 2021 2:30 AM > > On Fri, Jul 16, 2021 at 01:20:15AM +0000, Tian, Kevin wrote: > > > One thought is to have vfio device driver deal with it. In this proposal > > it is the vfio device driver to define the PASID virtualization policy and > > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands > > the restriction thus could just hide the vPASID capability when the user > > calls GET_INFO on the 2nd mdev in above scenario. In this way the > > user even doesn't need to know such restriction at all and both mdevs > > can be assigned to a single VM w/o any problem. > > I think it makes more sense to expose some kind of "pasid group" to > qemu that identifies that each PASID must be unique across the > group. For vIOMMUs that are doing funky things with the RID This means > a single PASID group must not be exposed as two RIDs to the guest. > It's an interesting idea. Some aspects are still unclear to me now e.g. how to describe such restriction in a way that it's applied only to a single user owning the group (not the case when assigned to different users), whether it can be generalized cross subsystems (vPASID being a vfio-managed resource), etc. Let's refine it when working on the actual implementation. > If the kernel blocks it then it can never be fixed by updating the > vIOMMU design. > But the mdev driver can choose to do so. Should we prevent it? btw just be curious whether you have got a chance to have a full review on v2. I wonder when might be a good time to discuss the execution plan following this proposal, if no major open remains... Thanks Kevin
