On Sat, Jun 03 2023, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> On Fri, 02 Jun 2023 23:14:47 +0100,
> Suraj Jitindar Singh <surajjs@xxxxxxxxxx> 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@xxxxxxxxxx>
>> ---
>> 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?
