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

From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
	Shenming Lu <lushenming@huawei.com>,
	"Alex Williamson (alex.williamson@redhat.com)" 
	<alex.williamson@redhat.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Jason Wang <jasowang@redhat.com>,
	"parav@mellanox.com" <parav@mellanox.com>,
	"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Eric Auger <eric.auger@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	"Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Robin Murphy <robin.murphy@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>
Subject: RE: [RFC v2] /dev/iommu uAPI proposal
Date: Wed, 21 Jul 2021 02:11:12 +0000	[thread overview]
Message-ID: <BN9PR11MB5433D6313D75EA10919ABE818CE39@BN9PR11MB5433.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210716183014.GN543781@nvidia.com>

> From: Jason Gunthorpe <jgg@nvidia.com>
> 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