On Tue, Jun 06 2023, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> On Mon, 05 Jun 2023 17:39:50 +0100,
> Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>>
>> 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?
>
> 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...
