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. Other things that we'll want to describe are fault reporting capability and PASID range, which would fit better in vfio_device_info. Thanks, Jean
