Re: [PATCH] iommu/arm-smmu-v3: Improve uAPI comment for IOMMU_HW_INFO_TYPE_ARM_SMMUV3

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Nov 15, 2024 at 08:27:12AM +0000, Tian, Kevin wrote:
> > - * a VMM is using this information to construct emulated copies of these
> > - * registers it should only forward bits that it knows it can support.
> > + * idr[0]: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN , CD2L,
> > ASID16, TTF
> > + * idr[1]: SIDSIZE, SSIDSIZE
> > + * idr[3]: BBML, RIL
> > + * idr[5]: VAX, GRAN64K, GRAN16K, GRAN4K
> >   *
> > - * In future, presence of required kernel support will be indicated in flags.
> 
> probably add a umbrella sentence to mark out following features not
> reported via IDRs

 *
 * The following bits in the vIDR should be obtained from other sources:
 * - S1P should be assumed to be true if a NESTED HWPT can be created

> 
> > + * - S1P should be assumed to be true if a NESTED HWPT can be created
> > + * - VFIO/iommufd only support platforms with COHACC, it should be
> > assumed to be
> > + *   true.
> > + * - ATS is a per-device property. If the VMM describes any devices as ATS
> > + *   capable in ACPI/DT it should set the corresponding idr.
> > + *
> > + * This list may expand in future (eg E0PD, AIE, PBHA, D128, DS etc). It is
> > + * important that VMMs do not read bits outside the list to allow for
> > + * compatibility with future kernels. Several features in the SMMUv3
> > + * architecture are not currently supported by the kernel for nesting: HTTU,
> > + * BTM, MPAM and others.
> 
> Not sure why HTTU etc. are remarked separately instead of appending to
> the list of E0PD etc. 

We know HTTU requires a kernel change, E0PD I think won't.

> there is a reason for kernel not reporting a certain feature now, no
> matter it's because the kernel hasn't supported it or supported it
> but just doesn't want to report. Knowing the difference doesn't help
> the business in VMM...

Right, it doesn't help the VMM, this is more guidance for future
people that might want to enable these things.

Thanks,
Jason