All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Joey Gouly <joey.gouly@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	Dave Martin <Dave.Martin@arm.com>, Fuad Tabba <tabba@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	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
Subject: Re: [PATCH v6 18/28] KVM: arm64: Support SME priority registers
Date: Sun, 29 Jun 2025 10:32:23 +0100	[thread overview]
Message-ID: <86o6u6c2qg.wl-maz@kernel.org> (raw)
In-Reply-To: <20250625-kvm-arm64-sme-v6-18-114cff4ffe04@kernel.org>

On Wed, 25 Jun 2025 11:48:09 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> SME has optional support for configuring the relative priorities of PEs
> in systems where they share a single SME hardware block, known as a
> SMCU. Currently we do not have any support for this in Linux and will
> also hide it from KVM guests, pending experience with practical
> implementations. The interface for configuring priority support is via
> two new system registers, these registers are always defined when SME is
> available.
> 
> The register SMPRI_EL1 allows control of SME execution priorities. Since
> we disable SME priority support for guests this register is RES0, define
> it as such and enable fine grained traps for SMPRI_EL1 to ensure that
> guests can't write to it even if the hardware supports priorites.  Since
> the register should be readable with fixed contents we only trap writes,
> not reads.
> 
> There is also an EL2 register SMPRIMAP_EL2 for virtualisation of
> priorities, this is RES0 when priority configuration is not supported
> but has no specific traps available.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/kvm_host.h     |  2 ++
>  arch/arm64/include/asm/vncr_mapping.h |  1 +
>  arch/arm64/kvm/sys_regs.c             | 23 ++++++++++++++++++++++-
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 29b8697c8144..5ce9e06324b5 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -495,6 +495,7 @@ enum vcpu_sysreg {
>  	SVCR,
>  	FPMR,
>  	SMIDR_EL1,	/* Streaming Mode Identification Register */
> +	SMPRI_EL1,	/* Streaming Mode Priority Register */
>

What is the point of making the sysreg file larger for the sole
purpose of returning a value that is firmly always 0? Can't that be
synthesised on the fly whenever needed?

>  	/* 32bit specific registers. */
>  	DACR32_EL2,	/* Domain Access Control Register */
> @@ -547,6 +548,7 @@ enum vcpu_sysreg {
>  	VNCR(CPACR_EL1),/* Coprocessor Access Control */
>  	VNCR(ZCR_EL1),	/* SVE Control */
>  	VNCR(SMCR_EL1),	/* SME Control */
> +	VNCR(SMPRIMAP_EL2),	/* Streaming Mode Priority Mapping Register */

This is slightly different, as there is no trap for this, and we rely
on sanitisation.

>  	VNCR(TTBR0_EL1),/* Translation Table Base Register 0 */
>  	VNCR(TTBR1_EL1),/* Translation Table Base Register 1 */
>  	VNCR(TCR_EL1),	/* Translation Control Register */
> diff --git a/arch/arm64/include/asm/vncr_mapping.h b/arch/arm64/include/asm/vncr_mapping.h
> index aede5d6efad3..454e076b77cb 100644
> --- a/arch/arm64/include/asm/vncr_mapping.h
> +++ b/arch/arm64/include/asm/vncr_mapping.h
> @@ -45,6 +45,7 @@
>  #define VNCR_ZCR_EL1            0x1E0
>  #define VNCR_HAFGRTR_EL2	0x1E8
>  #define VNCR_SMCR_EL1		0x1F0
> +#define VNCR_SMPRIMAP_EL2	0x1F0
>  #define VNCR_TTBR0_EL1          0x200
>  #define VNCR_TTBR1_EL1          0x210
>  #define VNCR_FAR_EL1            0x220
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index b11bb95e9e35..1fee8e534615 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1828,6 +1828,15 @@ static unsigned int fp8_visibility(const struct kvm_vcpu *vcpu,
>  	return REG_HIDDEN;
>  }
>  
> +static unsigned int sme_raz_visibility(const struct kvm_vcpu *vcpu,
> +				       const struct sys_reg_desc *rd)
> +{
> +	if (vcpu_has_sme(vcpu))
> +		return REG_RAZ;
> +
> +	return REG_HIDDEN;
> +}
> +
>  static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
>  {
>  	if (!vcpu_has_sve(vcpu))
> @@ -3030,7 +3039,14 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  
>  	{ SYS_DESC(SYS_ZCR_EL1), NULL, reset_val, ZCR_EL1, 0, .visibility = sve_visibility },
>  	{ SYS_DESC(SYS_TRFCR_EL1), undef_access },
> -	{ SYS_DESC(SYS_SMPRI_EL1), undef_access },
> +
> +	/*
> +	 * SMPRI_EL1 is UNDEF when SME is disabled, the UNDEF is
> +	 * handled via FGU which is handled without consulting this
> +	 * table.
> +	 */
> +	{ SYS_DESC(SYS_SMPRI_EL1), trap_raz_wi, .visibility = sme_raz_visibility },
> +
>  	{ SYS_DESC(SYS_SMCR_EL1), NULL, reset_val, SMCR_EL1, 0, .visibility = sme_visibility },
>  	{ SYS_DESC(SYS_TTBR0_EL1), access_vm_reg, reset_unknown, TTBR0_EL1 },
>  	{ SYS_DESC(SYS_TTBR1_EL1), access_vm_reg, reset_unknown, TTBR1_EL1 },
> @@ -3387,6 +3403,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  
>  	EL2_REG_VNCR(HCRX_EL2, reset_val, 0),
>  
> +	EL2_REG_FILTERED(SMPRIMAP_EL2, trap_raz_wi, reset_val, 0,
> +			 sme_el2_visibility),

Wut??? You clearly said it yourself: this register "has no specific
traps available". If you end-up here from a guest access, this is a
bug. So this "trap_raz_wi" makes no sense.

I also cannot see where this register is properly configured to be
fully RES0, as it should.

	M.

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

  reply	other threads:[~2025-06-29  9:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25 10:47 [PATCH v6 00/28] KVM: arm64: Implement support for SME Mark Brown
2025-06-25 10:47 ` [PATCH v6 01/28] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state Mark Brown
2025-06-25 10:47 ` [PATCH v6 02/28] arm64/fpsimd: Decide to save ZT0 and streaming mode FFR at bind time Mark Brown
2025-06-25 10:47 ` [PATCH v6 03/28] arm64/fpsimd: Check enable bit for FA64 when saving EFI state Mark Brown
2025-06-25 10:47 ` [PATCH v6 04/28] arm64/fpsimd: Determine maximum virtualisable SME vector length Mark Brown
2025-06-25 10:47 ` [PATCH v6 05/28] KVM: arm64: Introduce non-UNDEF FGT control Mark Brown
2025-06-25 10:47 ` [PATCH v6 06/28] KVM: arm64: Pay attention to FFR parameter in SVE save and load Mark Brown
2025-06-25 10:47 ` [PATCH v6 07/28] KVM: arm64: Pull ctxt_has_ helpers to start of sysreg-sr.h Mark Brown
2025-06-25 10:47 ` [PATCH v6 08/28] KVM: arm64: Move SVE state access macros after feature test macros Mark Brown
2025-06-25 10:48 ` [PATCH v6 09/28] KVM: arm64: Rename SVE finalization constants to be more general Mark Brown
2025-06-25 10:48 ` [PATCH v6 10/28] KVM: arm64: Document the KVM ABI for SME Mark Brown
2025-06-25 10:48 ` [PATCH v6 11/28] KVM: arm64: Define internal features " Mark Brown
2025-06-25 10:48 ` [PATCH v6 12/28] KVM: arm64: Rename sve_state_reg_region Mark Brown
2025-06-25 10:48 ` [PATCH v6 13/28] KVM: arm64: Store vector lengths in an array Mark Brown
2025-06-25 10:48 ` [PATCH v6 14/28] KVM: arm64: Implement SME vector length configuration Mark Brown
2025-06-25 10:48 ` [PATCH v6 15/28] KVM: arm64: Support SME control registers Mark Brown
2025-06-25 10:48 ` [PATCH v6 16/28] KVM: arm64: Support TPIDR2_EL0 Mark Brown
2025-06-25 10:48 ` [PATCH v6 17/28] KVM: arm64: Support SME identification registers for guests Mark Brown
2025-06-29 10:08   ` Marc Zyngier
2025-06-25 10:48 ` [PATCH v6 18/28] KVM: arm64: Support SME priority registers Mark Brown
2025-06-29  9:32   ` Marc Zyngier [this message]
2025-07-03 18:03     ` Mark Brown
2025-06-25 10:48 ` [PATCH v6 19/28] KVM: arm64: Provide assembly for SME register access Mark Brown
2025-06-25 10:48 ` [PATCH v6 20/28] KVM: arm64: Support userspace access to streaming mode Z and P registers Mark Brown
2025-06-25 10:48 ` [PATCH v6 21/28] KVM: arm64: Flush register state on writes to SVCR.SM and SVCR.ZA Mark Brown
2025-06-25 10:48 ` [PATCH v6 22/28] KVM: arm64: Expose SME specific state to userspace Mark Brown
2025-06-25 10:48 ` [PATCH v6 23/28] KVM: arm64: Context switch SME state for guests Mark Brown
2025-06-25 10:48 ` [PATCH v6 24/28] KVM: arm64: Handle SME exceptions Mark Brown
2025-06-25 10:48 ` [PATCH v6 25/28] KVM: arm64: Expose SME to nested guests Mark Brown
2025-06-25 10:48 ` [PATCH v6 26/28] KVM: arm64: Provide interface for configuring and enabling SME for guests Mark Brown
2025-06-25 10:48 ` [PATCH v6 27/28] KVM: arm64: selftests: Add SME system registers to get-reg-list Mark Brown
2025-06-25 10:48 ` [PATCH v6 28/28] KVM: arm64: selftests: Add SME to set_id_regs test 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=86o6u6c2qg.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Dave.Martin@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=joey.gouly@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=mark.rutland@arm.com \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --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.