On 2024-11-04 12:41 pm, Jason Gunthorpe wrote:
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.
But how *is* a VMM supposed to know what it can support? Are they all
expected to grovel the host devicetree/ACPI tables and maintain their
own knowledge of implementation errata to understand what's actually usable?
+ *
+ * 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.
That doesn't seem like a valid argument. We obviously can't abstract
SMMU_IIDR, that would indeed be an invitation for trouble, but
otherwise, if an erratum affects S1 operation under conditions dependent
on an optional feature, then not advertising that feature would make the
workaround irrelevant anyway, since as far as the VM is concerned it
would be wrong to expect a non-existent feature to work in the first place.
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.
What does S2 HTTU have to do with the VM? How the host wants to maintain
its S2 tables it its own business. AFAICS, unless the VMM wants to do
some fiddly CD shadowing, it's going to be kinda hard to prevent the
SMMU seeing a guest CD with CD.HA and/or CD.HD set if the guest expects
S1 HTTU to work.
I'm not sure what "vSTE that needs BTM" means. Even if the system does
support BTM, the only control is the global SMMU_CR2.PTM, and a vSMMU
can't usefully emulate changing that either way. Either the host set
PTM=0 before enabling the SMMU, so BTM can be advertised and expected to
work, or it didn't, in which case there can be no BTM, full stop.
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.
I would say it does. Advertising a feature when we already know it's not
usable at all puts a non-trivial and unnecessary burden on the VMM and
VM to then have to somehow derive that information from other sources,
at the risk of being confused by unexpected behaviour if they don't.
We sanitise CPU ID registers for userspace and KVM, so I see no
compelling reason for SMMU ID registers to be different.
Thanks,
Robin.
