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

[Marc Zyngier]

On Mon, 05 Jun 2023 17:39:50 +0100,
Cornelia Huck <cohuck at redhat.com> wrote:
> 
> On Sat, Jun 03 2023, Marc Zyngier <maz at kernel.org> wrote:
> 
> > On Fri, 02 Jun 2023 23:14:47 +0100,
> > Suraj Jitindar Singh <surajjs at amazon.com> wrote:
> >> 
> >> 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 <surajjs at amazon.com>
> >> ---
> >>  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?

Yeah, that. You get ID_AA64PFR1_EL1.{MTE,MTE_frac,MTEX}, plus
ID_AA64PFR2_EL1.{MTEFAR,MTESTOREONLY,MTEPERM}... It this sounds like a
train wreck, then it probably is one!

> 
> > 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?

It absolutely needs to be VM-wide. Only having half the vcpus
supporting tags wouldn't make much sense.

But the problem is that the various versions of MTE are not
necessarily compatible, as MTE4 makes MTE3 optional (with a fallback
to MTE2)... There are more subtleties around the what instructions are
available in which mode, and whether the various subfeatures can be
configured or not.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.