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

From: Marc Zyngier <maz@kernel.org>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Suraj Jitindar Singh <surajjs@amazon.com>,
	jingzhangos@google.com, alexandru.elisei@arm.com,
	james.morse@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, oupton@google.com,
	pbonzini@redhat.com, rananta@google.com, reijiw@google.com,
	suzuki.poulose@arm.com, tabba@google.com, will@kernel.org,
	sjitindarsingh@gmail.com
Subject: Re: [PATCH 3/3] KVM: arm64: Use per guest ID register for ID_AA64PFR1_EL1.MTE
Date: Tue, 06 Jun 2023 17:42:24 +0100	[thread overview]
Message-ID: <87legwo83z.wl-maz@kernel.org> (raw)
In-Reply-To: <87h6rl50dl.fsf@redhat.com>

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

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