All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: 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: Sat, 03 Jun 2023 09:28:33 +0100	[thread overview]
Message-ID: <873539ospa.wl-maz@kernel.org> (raw)
In-Reply-To: <20230602221447.1809849-4-surajjs@amazon.com>

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/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 7b0f43373dbe..861997a14ba1 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -226,9 +226,7 @@ struct kvm_arch {
>  	 */
>  #define KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER	0
>  	/* Memory Tagging Extension enabled for the guest */
> -#define KVM_ARCH_FLAG_MTE_ENABLED			1
> -	/* At least one vCPU has ran in the VM */
> -#define KVM_ARCH_FLAG_HAS_RAN_ONCE			2
> +#define KVM_ARCH_FLAG_HAS_RAN_ONCE			1
>  	/*
>  	 * The following two bits are used to indicate the guest's EL1
>  	 * register width configuration. A value of KVM_ARCH_FLAG_EL1_32BIT
> @@ -236,22 +234,22 @@ struct kvm_arch {
>  	 * Otherwise, the guest's EL1 register width has not yet been
>  	 * determined yet.
>  	 */
> -#define KVM_ARCH_FLAG_REG_WIDTH_CONFIGURED		3
> -#define KVM_ARCH_FLAG_EL1_32BIT				4
> +#define KVM_ARCH_FLAG_REG_WIDTH_CONFIGURED		2
> +#define KVM_ARCH_FLAG_EL1_32BIT				3
>  	/* PSCI SYSTEM_SUSPEND enabled for the guest */
> -#define KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED		5
> +#define KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED		4
>  	/* VM counter offset */
> -#define KVM_ARCH_FLAG_VM_COUNTER_OFFSET			6
> +#define KVM_ARCH_FLAG_VM_COUNTER_OFFSET			5
>  	/* Timer PPIs made immutable */
> -#define KVM_ARCH_FLAG_TIMER_PPIS_IMMUTABLE		7
> +#define KVM_ARCH_FLAG_TIMER_PPIS_IMMUTABLE		6
>  	/* SMCCC filter initialized for the VM */
> -#define KVM_ARCH_FLAG_SMCCC_FILTER_CONFIGURED		8
> +#define KVM_ARCH_FLAG_SMCCC_FILTER_CONFIGURED		7
>  	/*
>  	 * AA64DFR0_EL1.PMUver was set as ID_AA64DFR0_EL1_PMUVer_IMP_DEF
>  	 * or DFR0_EL1.PerfMon was set as ID_DFR0_EL1_PerfMon_IMPDEF from
>  	 * userspace for VCPUs without PMU.
>  	 */
> -#define KVM_ARCH_FLAG_VCPU_HAS_IMP_DEF_PMU		9
> +#define KVM_ARCH_FLAG_VCPU_HAS_IMP_DEF_PMU		8
>  
>  	unsigned long flags;
>  
> @@ -1112,7 +1110,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
>  
>  #define kvm_has_mte(kvm)					\
>  	(system_supports_mte() &&				\
> -	 test_bit(KVM_ARCH_FLAG_MTE_ENABLED, &(kvm)->arch.flags))
> +	 FIELD_GET(ID_AA64PFR1_EL1_MTE_MASK,			\
> +		   IDREG(kvm, SYS_ID_AA64PFR1_EL1)))
>  
>  #define kvm_supports_32bit_el0()				\
>  	(system_supports_32bit_el0() &&				\
> 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. Why are you
actively crippling the MTE version presented to the guest, and
potentially introduce unexpected behaviours?

> +			IDREG(kvm, SYS_ID_AA64PFR1_EL1) = val;
> +
> +			mutex_unlock(&kvm->arch.config_lock);
>  			r = 0;
> -			set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
>  		}
>  		mutex_unlock(&kvm->lock);
>  		break;
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 59f8adda47fa..8cffb82dd10d 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -3672,6 +3672,11 @@ void kvm_arm_init_id_regs(struct kvm *kvm)
>  		idreg++;
>  		id = reg_to_encoding(idreg);
>  	}
> +
> +	/* MTE disabled by default even when supported */
> +	val = IDREG(kvm, SYS_ID_AA64PFR1_EL1);
> +	val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
> +	IDREG(kvm, SYS_ID_AA64PFR1_EL1) = val;
>  }
>  
>  int __init kvm_sys_reg_table_init(void)

Overall, I don't really see the point of such a change. It creates
more problems than it solves.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: 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: Sat, 03 Jun 2023 09:28:33 +0100	[thread overview]
Message-ID: <873539ospa.wl-maz@kernel.org> (raw)
In-Reply-To: <20230602221447.1809849-4-surajjs@amazon.com>

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/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 7b0f43373dbe..861997a14ba1 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -226,9 +226,7 @@ struct kvm_arch {
>  	 */
>  #define KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER	0
>  	/* Memory Tagging Extension enabled for the guest */
> -#define KVM_ARCH_FLAG_MTE_ENABLED			1
> -	/* At least one vCPU has ran in the VM */
> -#define KVM_ARCH_FLAG_HAS_RAN_ONCE			2
> +#define KVM_ARCH_FLAG_HAS_RAN_ONCE			1
>  	/*
>  	 * The following two bits are used to indicate the guest's EL1
>  	 * register width configuration. A value of KVM_ARCH_FLAG_EL1_32BIT
> @@ -236,22 +234,22 @@ struct kvm_arch {
>  	 * Otherwise, the guest's EL1 register width has not yet been
>  	 * determined yet.
>  	 */
> -#define KVM_ARCH_FLAG_REG_WIDTH_CONFIGURED		3
> -#define KVM_ARCH_FLAG_EL1_32BIT				4
> +#define KVM_ARCH_FLAG_REG_WIDTH_CONFIGURED		2
> +#define KVM_ARCH_FLAG_EL1_32BIT				3
>  	/* PSCI SYSTEM_SUSPEND enabled for the guest */
> -#define KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED		5
> +#define KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED		4
>  	/* VM counter offset */
> -#define KVM_ARCH_FLAG_VM_COUNTER_OFFSET			6
> +#define KVM_ARCH_FLAG_VM_COUNTER_OFFSET			5
>  	/* Timer PPIs made immutable */
> -#define KVM_ARCH_FLAG_TIMER_PPIS_IMMUTABLE		7
> +#define KVM_ARCH_FLAG_TIMER_PPIS_IMMUTABLE		6
>  	/* SMCCC filter initialized for the VM */
> -#define KVM_ARCH_FLAG_SMCCC_FILTER_CONFIGURED		8
> +#define KVM_ARCH_FLAG_SMCCC_FILTER_CONFIGURED		7
>  	/*
>  	 * AA64DFR0_EL1.PMUver was set as ID_AA64DFR0_EL1_PMUVer_IMP_DEF
>  	 * or DFR0_EL1.PerfMon was set as ID_DFR0_EL1_PerfMon_IMPDEF from
>  	 * userspace for VCPUs without PMU.
>  	 */
> -#define KVM_ARCH_FLAG_VCPU_HAS_IMP_DEF_PMU		9
> +#define KVM_ARCH_FLAG_VCPU_HAS_IMP_DEF_PMU		8
>  
>  	unsigned long flags;
>  
> @@ -1112,7 +1110,8 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
>  
>  #define kvm_has_mte(kvm)					\
>  	(system_supports_mte() &&				\
> -	 test_bit(KVM_ARCH_FLAG_MTE_ENABLED, &(kvm)->arch.flags))
> +	 FIELD_GET(ID_AA64PFR1_EL1_MTE_MASK,			\
> +		   IDREG(kvm, SYS_ID_AA64PFR1_EL1)))
>  
>  #define kvm_supports_32bit_el0()				\
>  	(system_supports_32bit_el0() &&				\
> 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. Why are you
actively crippling the MTE version presented to the guest, and
potentially introduce unexpected behaviours?

> +			IDREG(kvm, SYS_ID_AA64PFR1_EL1) = val;
> +
> +			mutex_unlock(&kvm->arch.config_lock);
>  			r = 0;
> -			set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
>  		}
>  		mutex_unlock(&kvm->lock);
>  		break;
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 59f8adda47fa..8cffb82dd10d 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -3672,6 +3672,11 @@ void kvm_arm_init_id_regs(struct kvm *kvm)
>  		idreg++;
>  		id = reg_to_encoding(idreg);
>  	}
> +
> +	/* MTE disabled by default even when supported */
> +	val = IDREG(kvm, SYS_ID_AA64PFR1_EL1);
> +	val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
> +	IDREG(kvm, SYS_ID_AA64PFR1_EL1) = val;
>  }
>  
>  int __init kvm_sys_reg_table_init(void)

Overall, I don't really see the point of such a change. It creates
more problems than it solves.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-06-03  8:28 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 [this message]
2023-06-03  8:28       ` Marc Zyngier
2023-06-05 16:39       ` Cornelia Huck
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=873539ospa.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --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=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.