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

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Mar 20, 2025 at 04:48:33PM -0700, Nicolin Chen wrote:
> > > 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?
> 
> Hmm, I thought hw_info is all about a single IOMMU instance.
> 
> Although the ioctl is per-device operation, it feels odd that
> different devices behind the same IOMMU will return different
> copies of "IOMMU" hw_info for that IOMMU HW..

Reading this further, I found that Yi did report VFIO device cap
for PASID via a VFIO ioctl in the early versions but switched to
using the IOMMU_GET_HW_INFO since v3 (nearly a year ago). So, I
see that's a made decision.

Given that our IOMMU_GET_HW_INFO defines this:
  * Query an iommu type specific hardware information data from an iommu behind
  * a given device that has been bound to iommufd. This hardware info data will
  * be used to sync capabilities between the virtual iommu and the physical
  * iommu, e.g. a nested translation setup needs to check the hardware info, so
  * a guest stage-1 page table can be compatible with the physical iommu.

max_pasid_log2 is something that fits well. But PCI device cap
still feels odd in that regard, as it repurposes the ioctl.

So, perhaps we should update the uAPI documentation and ask user
space to run IOMMU_GET_HW_INFO for every iommufd_device, because
the output out_capabilities may be different per iommufd_device,
even if both devices are correctly assigned to the same vIOMMU.

Thanks
Nicolin