RE: [RFC v2] /dev/iommu uAPI proposal

[Tian, Kevin]

> 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