> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Tuesday, December 10, 2024 11:15 AM > > On 2024/12/9 22:57, Jason Gunthorpe wrote: > > > > I'm not sure, I think we should not make it dependent on the device > > capability. There may be multiple devices in the iommufd and some of > > them may be PASID capable. The PASID capable domains should interwork > > with all of the devices. Thus I'd also expect to be able to allocate a > > PASID capable domain on a non-pasid capable device. Even though that > > would be pointless on its own. > > yes. I also had an offline email to confirm with Vasant, and he confirmed > a non-pasid capable device should be able to use pasid-capable domain (V2 > page table. It's hard to think any vendor would want to that type of restriction. whatever format adopted is purely IOMMU internal thing. > > > > We want some reasonable compromise to encourage applications to use > > IOMMU_HWPT_ALLOC_PASID properly, but not build too much complexity > to > > reject driver-specific behavior. > > I'm ok to do it in iommufd as long as it is only applicable to hwpt_paging. > Otherwise, attaching nested domain to pasid would be failed according to > the aforementioned enforcement. > IMHO we may want to have a general enforcement in IOMMUFD that any domain (paging or nested) must have ALLOC_PASID set to be used in pasid-oriented operations. drivers can have more restrictions, e.g. for arm/amd allocating a nested domain with that bit set will fail at the beginning.
