On Tue, 18 Jul 2017 10:38:40 +0100 Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx> wrote: > On 17/07/17 23:45, Alex Williamson wrote: > [..] > >>> > >>> How does a user learn which model(s) are supported by the interface? > >>> How do they learn which ops are supported? Perhaps a good use for one of those > >>> flag bits in the outer data structure is "probe". > >> > >> My initial plan to user fills it, if the underlying HW doesn't support the > >> model, it refuses to service it. User should get a failure and stop to use > >> it. But your suggestion to have a probe or kinds of query makes sense. > >> How about we add one more operation for such purpose? Besides the > >> supported model query, I'd like to add more. E.g the HW IOMMU capabilities. > > > > We also have VFIO_IOMMU_GET_INFO where the structure can be extended > > for missing capabilities. Depending on the capability you want to > > describe, this might be a better, existing interface for it. > > It might become hairy when physical IOMMUs start supporting multiple > formats, or when we want to describe multiple page table formats in > addition to PASID tables. I was wondering if sysfs iommu_group would be > better suited for this kind of hardware description with variable-length > properties, but a new ioctl-based probing mechanism would work as well. Would different groups have different properties? Perhaps it's related to the iommu hardware unit supporting the device, which could host one or more groups. Each device already has a link to its iommu where we could add info (/sys/class/iommu/). > Other things that we'll want to describe are fault reporting capability > and PASID range, which would fit better in vfio_device_info. Why? The per device PASID info is in a PCI capability, so wouldn't this be iommu info? Isn't the fault reporting also via the iommu? Thanks, Alex
