[PATCH v10 01/30] arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06
Mark Rutland
mark.rutland at arm.com
Fri May 8 10:12:01 PDT 2026
On Fri, Mar 06, 2026 at 05:00:53PM +0000, Mark Brown wrote:
> Update the definition of SMIDR_EL1 in the sysreg definition to reflect the
> information in DD0601 2025-06. This includes somewhat more generic ways of
> describing the sharing of SMCUs, more information on supported priorities
> and provides additional resolution for describing affinity groups.
FWIW, these are all in ARM DDI 0487 M.b:
https://developer.arm.com/documentation/ddi0487/mb/
Is anything later in the series going to depend on these fields, or
would everything behave correctly with the existing RES0 field
definitions?
> Reviewed-by: Fuad Tabba <tabba at google.com>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
> arch/arm64/tools/sysreg | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 9d1c21108057..b6586accf344 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -3655,11 +3655,15 @@ Field 3:0 BS
> EndSysreg
>
> Sysreg SMIDR_EL1 3 1 0 0 6
> -Res0 63:32
> +Res0 63:60
> +Field 59:56 NSMC
> +Field 55:52 HIP
Reading the ARM ARM, HIP is arguably a backwards-incompatible change.
Do we expect to expose that to VMs, or just hide priorities entirely? I
suspect we probably want to require that the guest sees
SMIDR_EL1.SMPS==0, and not care about any of that.
Mark.
> +Field 51:32 AFFINITY2
> Field 31:24 IMPLEMENTER
> Field 23:16 REVISION
> Field 15 SMPS
> -Res0 14:12
> +Field 14:13 SH
> +Res0 12
> Field 11:0 AFFINITY
> EndSysreg
>
>
> --
> 2.47.3
>
More information about the linux-arm-kernel
mailing list