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
