All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 James Morse <james.morse@arm.com>,
	 Suzuki K Poulose <suzuki.poulose@arm.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,  Shuah Khan <shuah@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	 linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	 linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	 Mark Brown <broonie@kernel.org>
Subject: [PATCH RFC v2 20/22] KVM: arm64: Support SME version configuration via ID registers
Date: Fri, 22 Dec 2023 16:21:28 +0000	[thread overview]
Message-ID: <20231222-kvm-arm64-sme-v2-20-da226cb180bb@kernel.org> (raw)
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>

As well as a substantial set of features which provide additional
instructions there are also two current extensions which add new
architectural state, SME2 (which adds ZT) and FA64 (which makes
FFR valid in streaming mode SVE). Allow all of these to be
configured through writes to the ID registers.

At present the guest support for SME2 and FA64 does not use the values
configured here pending clarity on the approach to be taken generally
with regards to parsing supported features from ID registers.

We always allocate state for the new architectural state which might be
enabled if the host supports it, in the case of FFR this simplifies the
already fiddly allocation and is needed when SVE is also supported. In
the case of ZT the register is 64 bytes which is not completely trivial
(though not so much relative to the other SME state) but it is not
expected that there will be many practical users that want SME1 only so
it is expected that guests with SME1 only would not be common enough to
justify the complication of handling this. If this proves to be a
problem we can improve things incrementally.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f908aa3fb606..1ea658615467 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1412,13 +1412,6 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
 	val = read_sanitised_ftr_reg(id);
 
 	switch (id) {
-	case SYS_ID_AA64PFR1_EL1:
-		if (!kvm_has_mte(vcpu->kvm))
-			val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
-
-		if (!vcpu_has_sme(vcpu))
-			val &= ~ID_AA64PFR1_EL1_SME_MASK;
-		break;
 	case SYS_ID_AA64ISAR1_EL1:
 		if (!vcpu_has_ptrauth(vcpu))
 			val &= ~(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA) |
@@ -1582,6 +1575,20 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
 	return val;
 }
 
+static u64 read_sanitised_id_aa64pfr1_el1(struct kvm_vcpu *vcpu,
+					  const struct sys_reg_desc *rd)
+{
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
+
+	if (!vcpu_has_sme(vcpu))
+		val &= ~ID_AA64PFR1_EL1_SME_MASK;
+
+	if (!kvm_has_mte(vcpu->kvm))
+		val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
+
+	return val;
+}
+
 #define ID_REG_LIMIT_FIELD_ENUM(val, reg, field, limit)			       \
 ({									       \
 	u64 __f_val = FIELD_GET(reg##_##field##_MASK, val);		       \
@@ -2164,7 +2171,14 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		   ID_AA64PFR0_EL1_GIC |
 		   ID_AA64PFR0_EL1_AdvSIMD |
 		   ID_AA64PFR0_EL1_FP), },
-	ID_SANITISED(ID_AA64PFR1_EL1),
+	{ SYS_DESC(SYS_ID_AA64PFR1_EL1),
+	  .access = access_id_reg,
+	  .get_user = get_id_reg,
+	  .set_user = set_id_reg,
+	  .reset = read_sanitised_id_aa64pfr1_el1,
+	  .val = ~(ID_AA64PFR1_EL1_MPAM_frac |
+		   ID_AA64PFR1_EL1_RAS_frac |
+		   ID_AA64PFR1_EL1_MTE), },
 	ID_UNALLOCATED(4,2),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),

-- 
2.30.2


WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 James Morse <james.morse@arm.com>,
	 Suzuki K Poulose <suzuki.poulose@arm.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,  Shuah Khan <shuah@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	 linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	 linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	 Mark Brown <broonie@kernel.org>
Subject: [PATCH RFC v2 20/22] KVM: arm64: Support SME version configuration via ID registers
Date: Fri, 22 Dec 2023 16:21:28 +0000	[thread overview]
Message-ID: <20231222-kvm-arm64-sme-v2-20-da226cb180bb@kernel.org> (raw)
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>

As well as a substantial set of features which provide additional
instructions there are also two current extensions which add new
architectural state, SME2 (which adds ZT) and FA64 (which makes
FFR valid in streaming mode SVE). Allow all of these to be
configured through writes to the ID registers.

At present the guest support for SME2 and FA64 does not use the values
configured here pending clarity on the approach to be taken generally
with regards to parsing supported features from ID registers.

We always allocate state for the new architectural state which might be
enabled if the host supports it, in the case of FFR this simplifies the
already fiddly allocation and is needed when SVE is also supported. In
the case of ZT the register is 64 bytes which is not completely trivial
(though not so much relative to the other SME state) but it is not
expected that there will be many practical users that want SME1 only so
it is expected that guests with SME1 only would not be common enough to
justify the complication of handling this. If this proves to be a
problem we can improve things incrementally.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f908aa3fb606..1ea658615467 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1412,13 +1412,6 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
 	val = read_sanitised_ftr_reg(id);
 
 	switch (id) {
-	case SYS_ID_AA64PFR1_EL1:
-		if (!kvm_has_mte(vcpu->kvm))
-			val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
-
-		if (!vcpu_has_sme(vcpu))
-			val &= ~ID_AA64PFR1_EL1_SME_MASK;
-		break;
 	case SYS_ID_AA64ISAR1_EL1:
 		if (!vcpu_has_ptrauth(vcpu))
 			val &= ~(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA) |
@@ -1582,6 +1575,20 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
 	return val;
 }
 
+static u64 read_sanitised_id_aa64pfr1_el1(struct kvm_vcpu *vcpu,
+					  const struct sys_reg_desc *rd)
+{
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
+
+	if (!vcpu_has_sme(vcpu))
+		val &= ~ID_AA64PFR1_EL1_SME_MASK;
+
+	if (!kvm_has_mte(vcpu->kvm))
+		val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
+
+	return val;
+}
+
 #define ID_REG_LIMIT_FIELD_ENUM(val, reg, field, limit)			       \
 ({									       \
 	u64 __f_val = FIELD_GET(reg##_##field##_MASK, val);		       \
@@ -2164,7 +2171,14 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		   ID_AA64PFR0_EL1_GIC |
 		   ID_AA64PFR0_EL1_AdvSIMD |
 		   ID_AA64PFR0_EL1_FP), },
-	ID_SANITISED(ID_AA64PFR1_EL1),
+	{ SYS_DESC(SYS_ID_AA64PFR1_EL1),
+	  .access = access_id_reg,
+	  .get_user = get_id_reg,
+	  .set_user = set_id_reg,
+	  .reset = read_sanitised_id_aa64pfr1_el1,
+	  .val = ~(ID_AA64PFR1_EL1_MPAM_frac |
+		   ID_AA64PFR1_EL1_RAS_frac |
+		   ID_AA64PFR1_EL1_MTE), },
 	ID_UNALLOCATED(4,2),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),

-- 
2.30.2


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

  parent reply	other threads:[~2023-12-22 16:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-22 16:21 [PATCH RFC v2 00/22] KVM: arm64: Implement support for SME in non-protected guests Mark Brown
2023-12-22 16:21 ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 01/22] KVM: arm64: Document why we trap SVE access from the host Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 02/22] arm64/fpsimd: Make SVE<->FPSIMD rewriting available to KVM Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 03/22] KVM: arm64: Move SVE state access macros after feature test macros Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 04/22] KVM: arm64: Store vector lengths in an array Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 05/22] KVM: arm64: Document the KVM ABI for SME Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 06/22] KVM: arm64: Make FFR restore optional in __sve_restore_state() Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 07/22] KVM: arm64: Define guest flags for SME Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 08/22] KVM: arm64: Rename SVE finalization constants to be more general Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 09/22] KVM: arm64: Basic SME system register descriptions Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 10/22] KVM: arm64: Add support for TPIDR2_EL0 Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 11/22] KVM: arm64: Make SMPRI_EL1 RES0 for SME guests Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 12/22] KVM: arm64: Make SVCR a normal system register Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 13/22] KVM: arm64: Context switch SME state for guest Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 14/22] KVM: arm64: Manage and handle SME traps Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 15/22] KVM: arm64: Implement SME vector length configuration Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 16/22] KVM: arm64: Rename sve_state_reg_region Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 17/22] KVM: arm64: Support userspace access to streaming mode SVE registers Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 18/22] KVM: arm64: Expose ZA to userspace Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 19/22] KVM: arm64: Provide userspace access to ZT0 Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` Mark Brown [this message]
2023-12-22 16:21   ` [PATCH RFC v2 20/22] KVM: arm64: Support SME version configuration via ID registers Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 21/22] KVM: arm64: Provide userspace ABI for enabling SME Mark Brown
2023-12-22 16:21   ` Mark Brown
2023-12-22 16:21 ` [PATCH RFC v2 22/22] KVM: arm64: selftests: Add SME system registers to get-reg-list Mark Brown
2023-12-22 16:21   ` Mark Brown

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=20231222-kvm-arm64-sme-v2-20-da226cb180bb@kernel.org \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=suzuki.poulose@arm.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.