From: Cornelia Huck <cohuck@redhat.com>
To: Marc Zyngier <maz@kernel.org>, Suraj Jitindar Singh <surajjs@amazon.com>
Cc: 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: Mon, 05 Jun 2023 18:39:50 +0200 [thread overview]
Message-ID: <87h6rl50dl.fsf@redhat.com> (raw)
In-Reply-To: <873539ospa.wl-maz@kernel.org>
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?
> 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?
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Marc Zyngier <maz@kernel.org>, Suraj Jitindar Singh <surajjs@amazon.com>
Cc: 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: Mon, 05 Jun 2023 18:39:50 +0200 [thread overview]
Message-ID: <87h6rl50dl.fsf@redhat.com> (raw)
In-Reply-To: <873539ospa.wl-maz@kernel.org>
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?
> 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?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-06-05 16:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 0:51 [PATCH v11 0/5] Support writable CPU ID registers from userspace Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 0:51 ` [PATCH v11 1/5] KVM: arm64: Save ID registers' sanitized value per guest Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 0:51 ` [PATCH v11 2/5] KVM: arm64: Use per guest ID register for ID_AA64PFR0_EL1.[CSV2|CSV3] Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 0:51 ` [PATCH v11 3/5] KVM: arm64: Use per guest ID register for ID_AA64DFR0_EL1.PMUVer Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 0:51 ` [PATCH v11 4/5] KVM: arm64: Reuse fields of sys_reg_desc for idreg Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 0:51 ` [PATCH v11 5/5] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3 Jing Zhang
2023-06-02 0:51 ` Jing Zhang
2023-06-02 17:15 ` Jing Zhang
2023-06-02 17:15 ` Jing Zhang
2023-06-02 22:27 ` Jitindar Singh, Suraj
2023-06-02 22:27 ` Jitindar Singh, Suraj
2023-06-03 0:08 ` Jing Zhang
2023-06-03 0:08 ` Jing Zhang
2023-06-02 19:21 ` Jitindar Singh, Suraj
2023-06-02 19:21 ` Jitindar Singh, Suraj
2023-06-03 0:03 ` Jing Zhang
2023-06-03 0:03 ` Jing Zhang
2023-06-02 22:14 ` [PATCH 0/3] RE: Support writable CPU ID registers from userspace [v11] Suraj Jitindar Singh
2023-06-02 22:14 ` Suraj Jitindar Singh
2023-06-02 22:14 ` [PATCH 1/3] KVM: arm64: Update id_reg limit value based on per vcpu flags Suraj Jitindar Singh
2023-06-02 22:14 ` Suraj Jitindar Singh
2023-06-02 22:14 ` [PATCH 2/3] KVM: arm64: Move non per vcpu flag checks out of kvm_arm_update_id_reg() Suraj Jitindar Singh
2023-06-02 22:14 ` Suraj Jitindar Singh
2023-06-02 22:14 ` [PATCH 3/3] KVM: arm64: Use per guest ID register for ID_AA64PFR1_EL1.MTE Suraj Jitindar Singh
2023-06-02 22:14 ` Suraj Jitindar Singh
2023-06-03 8:28 ` Marc Zyngier
2023-06-03 8:28 ` Marc Zyngier
2023-06-05 16:39 ` Cornelia Huck [this message]
2023-06-05 16:39 ` Cornelia Huck
2023-06-06 16:42 ` Marc Zyngier
2023-06-06 16:42 ` Marc Zyngier
2023-06-07 10:09 ` Cornelia Huck
2023-06-07 10:09 ` Cornelia Huck
2023-06-08 17:57 ` Catalin Marinas
2023-06-08 17:57 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6rl50dl.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=alexandru.elisei@arm.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=sjitindarsingh@gmail.com \
--cc=surajjs@amazon.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.