| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+EHjTwxc=+1TodVR7X96fnKu-mykivdFxMbB5nUrw_h4MGKHg@mail.gmail.com>
Date: Mon, 12 Jan 2026 11:59:22 +0000
From: Fuad Tabba <tabba@...gle.com>
To: Mark Brown <broonie@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Joey Gouly <joey.gouly@....com>,
Catalin Marinas <catalin.marinas@....com>, Suzuki K Poulose <suzuki.poulose@....com>,
Will Deacon <will@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Jonathan Corbet <corbet@....net>,
Shuah Khan <shuah@...nel.org>, Oliver Upton <oupton@...nel.org>, Dave Martin <Dave.Martin@....com>,
Mark Rutland <mark.rutland@....com>, Ben Horgan <ben.horgan@....com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kselftest@...r.kernel.org, Peter Maydell <peter.maydell@...aro.org>,
Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH v9 18/30] KVM: arm64: Support SME priority registers
Hi Mark,
On Tue, 23 Dec 2025 at 01:22, Mark Brown <broonie@...nel.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
nit: priorites -> priorities
> the register should be readable with fixed contents we only trap writes,
> not reads. Since there is no host support for using priorities the
> register currently left with a value of 0 by the host so we do not need
> to update the value for guests.
>
> 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. When saving state from a nested
> guest we overwite any value the guest stored.
nit: overwite -> overwrite
>
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/include/asm/vncr_mapping.h | 1 +
> arch/arm64/kvm/config.c | 3 +++
> arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 7 +++++++
> arch/arm64/kvm/sys_regs.c | 30 +++++++++++++++++++++++++++++-
> 5 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index fead6988f47c..44595a789a97 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -546,6 +546,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 */
> 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 44b12565321b..a2a84af6585b 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
This should be 0x1F8.
> #define VNCR_TTBR0_EL1 0x200
> #define VNCR_TTBR1_EL1 0x210
> #define VNCR_FAR_EL1 0x220
> diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> index 7e26991b2df1..0088635a95bd 100644
> --- a/arch/arm64/kvm/config.c
> +++ b/arch/arm64/kvm/config.c
> @@ -1481,6 +1481,9 @@ static void __compute_hfgwtr(struct kvm_vcpu *vcpu)
>
> if (cpus_have_final_cap(ARM64_WORKAROUND_AMPERE_AC03_CPU_38))
> *vcpu_fgt(vcpu, HFGWTR_EL2) |= HFGWTR_EL2_TCR_EL1;
> +
> + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, SME, IMP))
> + *vcpu_fgt(vcpu, HFGWTR_EL2) |= HFGWTR_EL2_nSMPRI_EL1;
Is the intention to _disable_ the trap in this case? I think you
wanted to enable them.
> }
>
> static void __compute_hdfgwtr(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> index f28c6cf4fe1b..07aa4378c58a 100644
> --- a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> @@ -80,6 +80,13 @@ static void __sysreg_save_vel2_state(struct kvm_vcpu *vcpu)
>
> if (ctxt_has_sctlr2(&vcpu->arch.ctxt))
> __vcpu_assign_sys_reg(vcpu, SCTLR2_EL2, read_sysreg_el1(SYS_SCTLR2));
> +
> + /*
> + * We block SME priorities so SMPRIMAP_EL2 is RES0, however we
> + * do not have traps to block access so the guest might have
> + * updated the state, overwrite anything there.
nit: overwrite -> overwriting
Cheers,
/fuad
> + */
> + __vcpu_assign_sys_reg(vcpu, SMPRIMAP_EL2, 0);
> }
>
> static void __sysreg_restore_vel2_state(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index a7ab02822023..51f175bbe8d1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -691,6 +691,15 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu,
> return read_zero(vcpu, p);
> }
>
> +static int set_res0(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
> + u64 val)
> +{
> + if (val)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /*
> * ARMv8.1 mandates at least a trivial LORegion implementation, where all the
> * RW registers are RES0 (which we can implement as RAZ/WI). On an ARMv8.0
> @@ -1979,6 +1988,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))
> @@ -3349,7 +3367,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 },
> @@ -3719,6 +3744,9 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>
> EL2_REG_VNCR(HCRX_EL2, reset_val, 0),
>
> + { SYS_DESC(SYS_SMPRIMAP_EL2), .reg = SMPRIMAP_EL2,
> + .access = trap_raz_wi, .set_user = set_res0, .reset = reset_val,
> + .val = 0, .visibility = sme_el2_visibility },
> EL2_REG_FILTERED(SMCR_EL2, access_smcr_el2, reset_val, 0,
> sme_el2_visibility),
>
>
> --
> 2.47.3
>
Powered by blists - more mailing lists