Re: [PATCH 3/3] KVM: arm64: Use per guest ID register for ID_AA64PFR1_EL1.MTE

On Sat, Jun 03 2023, Marc Zyngier [off-list ref] wrote:

On Fri, 02 Jun 2023 23:14:47 +0100,
Suraj Jitindar Singh [off-list ref] wrote:

quoted

With per guest ID registers, MTE settings from userspace can be stored in
its corresponding ID register.

No functional change intended.

Signed-off-by: Suraj Jitindar Singh <redacted>
---
 arch/arm64/include/asm/kvm_host.h | 21 ++++++++++-----------
 arch/arm64/kvm/arm.c              | 11 ++++++++++-
 arch/arm64/kvm/sys_regs.c         |  5 +++++
 3 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index ca18c09ccf82..6fc4190559d1 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c

@@ -80,8 +80,17 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
 		if (!system_supports_mte() || kvm->created_vcpus) {
 			r = -EINVAL;
 		} else {
+			u64 val;
+
+			/* Protects the idregs against modification */
+			mutex_lock(&kvm->arch.config_lock);
+
+			val = IDREG(kvm, SYS_ID_AA64PFR1_EL1);
+			val |= FIELD_PREP(ID_AA64PFR1_EL1_MTE_MASK, 1);

The architecture specifies 3 versions of MTE in the published ARM ARM,
with a 4th coming up as part of the 2022 extensions.

Is that the one that adds some more MTE<foo> bits in AA64PFR1 and
AA64PFR2?

Why are you
actively crippling the MTE version presented to the guest, and
potentially introduce unexpected behaviours?

While the code does not look correct here, I think we'll need some way to
control which version of MTE is presented to the guest for compatibility
handling; does it make sense to control this per-cpu, or does it need to
be a vm-wide setting?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel