Re: [PATCH v8 4/5] iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Mar 20, 2025 at 01:02:54PM -0700, Nicolin Chen wrote:
> On Thu, Mar 20, 2025 at 03:57:26PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 20, 2025 at 09:47:32AM -0700, Nicolin Chen wrote:
> > 
> > > In that regard, honestly, I don't quite get this out_capabilities.
> > 
> > Yeah, I think it is best thought of as place to put discoverability if
> > people want discoverability.
> > 
> > I have had a wait and see feeling in this area since I don't know what
> > qemu or libvirt would actually use.
> 
> Both ARM and Intel have max_pasid_log2 being reported somewhere
> in their vendor data structures. So, unless user space really
> wants that info immediately without involving the vendor IOMMU,
> this max_pasid_log2 seems to be redundant.

I don't expect that PASID support should require a userspace driver
component, it should work generically. So generic userspace should
have a generic way to get the pasid range.

> Also, this patch polls two IOMMU caps out of pci_pasid_status()
> that is a per device function. Is this okay?

I think so, the hw_info is a per-device operation

> Can it end up with two devices (one has PASID; the other doesn't)
> behind the same IOMMU reporting two different sets of
> out_capabilities, which were supposed to be the same since it the
> same IOMMU HW?

Yes it can report differences, but that is OK as the iommu is not
required to be uniform across all devices? Did you mean something else?

Jason