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

[Cornelia Huck]

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?

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