diff options
author | Ben Horgan <ben.horgan@arm.com> | 2025-05-12 12:41:11 +0100 |
---|---|---|
committer | Marc Zyngier <maz@kernel.org> | 2025-05-16 13:01:18 +0100 |
commit | fe21ff5d4b46c06c4e43a310fdb781d1e6b5173e (patch) | |
tree | 573a7fba40b3bd13bee3b110881b677dd48ce96f /scripts/lib/kdoc/kdoc_files.py | |
parent | 5799a2983fea4f22f6aaa291aee3b704db81d29f (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