summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_files.py
diff options
context:
space:
mode:
authorBen Horgan <ben.horgan@arm.com>2025-05-12 12:41:11 +0100
committerMarc Zyngier <maz@kernel.org>2025-05-16 13:01:18 +0100
commitfe21ff5d4b46c06c4e43a310fdb781d1e6b5173e (patch)
tree573a7fba40b3bd13bee3b110881b677dd48ce96f /scripts/lib/kdoc/kdoc_files.py
parent5799a2983fea4f22f6aaa291aee3b704db81d29f (diff)
KVM: arm64: Make MTE_frac masking conditional on MTE capability
If MTE_frac is masked out unconditionally then the guest will always see ID_AA64PFR1_EL1_MTE_frac as 0. However, a value of 0 when ID_AA64PFR1_EL1_MTE is 2 indicates that MTE_ASYNC is supported. Hence, for a host with ID_AA64PFR1_EL1_MTE==2 and ID_AA64PFR1_EL1_MTE_frac==0xf (MTE_ASYNC unsupported) the guest would see MTE_ASYNC advertised as supported whilst the host does not support it. Hence, expose the sanitised value of MTE_frac to the guest and user-space. As MTE_frac was previously hidden, always 0, and KVM must accept values from KVM provided by user-space, when ID_AA64PFR1_EL1.MTE is 2 allow user-space to set ID_AA64PFR1_EL1.MTE_frac to 0. However, ignore it to avoid incorrectly claiming hardware support for MTE_ASYNC in the guest. Note that linux does not check the value of ID_AA64PFR1_EL1_MTE_frac and wrongly assumes that MTE async faults can be generated even on hardware that does nto support them. This issue is not addressed here. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Link: https://lore.kernel.org/r/20250512114112.359087-3-ben.horgan@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_files.py')
0 files changed, 0 insertions, 0 deletions