On Mon, Nov 04, 2024 at 11:47:24AM +0000, Will Deacon wrote: > > +/** > > + * struct iommu_hw_info_arm_smmuv3 - ARM SMMUv3 hardware information > > + * (IOMMU_HW_INFO_TYPE_ARM_SMMUV3) > > + * > > + * @flags: Must be set to 0 > > + * @__reserved: Must be 0 > > + * @idr: Implemented features for ARM SMMU Non-secure programming interface > > + * @iidr: Information about the implementation and implementer of ARM SMMU, > > + * and architecture version supported > > + * @aidr: ARM SMMU architecture version > > + * > > + * For the details of @idr, @iidr and @aidr, please refer to the chapters > > + * from 6.3.1 to 6.3.6 in the SMMUv3 Spec. > > + * > > + * User space should read the underlying ARM SMMUv3 hardware information for > > + * the list of supported features. > > + * > > + * Note that these values reflect the raw HW capability, without any insight if > > + * any required kernel driver support is present. Bits may be set indicating the > > + * HW has functionality that is lacking kernel software support, such as BTM. If > > + * a VMM is using this information to construct emulated copies of these > > + * registers it should only forward bits that it knows it can support. > > + * > > + * In future, presence of required kernel support will be indicated in flags. > > What about the case where we _know_ that some functionality is broken in > the hardware? For example, we nobble BTM support on MMU 700 thanks to > erratum #2812531 yet we'll still cheerfully advertise it in IDR0 here. > Similarly, HTTU can be overridden by IORT, so should we update the view > that we advertise for that as well? My knee jerk answer is no, these struct fields should just report the raw HW register. A VMM should not copy these fields directly into a VM. The principle purpose is to give the VMM the same details about the HW as the kernel so it can apply erratas/etc. For instance, if we hide these fields how will the VMM/VM know to apply the various flushing errata? With vCMDQ/etc the VM is directly pushing flushes to HW, it must know the errata. For BTM/HTTU/etc - those all require kernel SW support and per-device permission in the kernel to turn on. For instance requesting a nested vSTE that needs BTM will fail today during attach. Turning on HTTU on the S2 already has an API that will fail if the IORT blocks it. Incrementally dealing with expanding the support is part of the "required kernel support will be indicated in flags." Basically, exposing the information as-is doesn't do any harm. Jason
