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

[Cornelia Huck]

On Tue, Jun 06 2023, Marc Zyngier <maz at kernel.org> wrote:

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

With that many features, what could possibly go wrong!

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

So I guess we'll have to expose all of that to userspace, so that it can
actually configure the various configurations that will surely show up
in the wild...