linux.git/arch/arm64/kernel/cpuinfo.c, branch v6.0

arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}

2022-07-25T10:02:11+00:00

Even if we are now able to tell the kernel to avoid exposing SVE/SME
from the command line, we still have a couple of places where we
unconditionally access the ZCR_EL1 (resp. SMCR_EL1) registers.

On systems with broken firmwares, this results in a crash even if
arm64.nosve (resp. arm64.nosme) was passed on the command-line.

To avoid this, only update cpuinfo_arm64::reg_{zcr,smcr} once
we have computed the sanitised version for the corresponding
feature registers (ID_AA64PFR0 for SVE, and ID_AA64PFR1 for
SME). This results in some minor refactoring.

Reviewed-by: Mark Brown 
Reviewed-by: Peter Collingbourne 
Tested-by: Peter Collingbourne 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20220720105219.1755096-1-maz@kernel.org
Signed-off-by: Will Deacon

Merge branch 'for-next/cpufeature' into for-next/core

2022-07-25T09:58:10+00:00

* for-next/cpufeature:
  arm64/hwcap: Support FEAT_EBF16
  arm64/cpufeature: Store elf_hwcaps as a bitmap rather than unsigned long
  arm64/hwcap: Document allocation of upper bits of AT_HWCAP
  arm64: trap implementation defined functionality in userspace

Merge branch 'for-next/sysregs' into for-next/core

2022-07-25T09:57:37+00:00

* for-next/sysregs: (28 commits)
  arm64/sysreg: Convert ID_AA64ZFR0_EL1 to automatic generation
  arm64/sysreg: Convert ID_AA64SMFR0_EL1 to automatic generation
  arm64/sysreg: Convert LORID_EL1 to automatic generation
  arm64/sysreg: Convert LORC_EL1 to automatic generation
  arm64/sysreg: Convert LORN_EL1 to automatic generation
  arm64/sysreg: Convert LOREA_EL1 to automatic generation
  arm64/sysreg: Convert LORSA_EL1 to automatic generation
  arm64/sysreg: Convert ID_AA64ISAR2_EL1 to automatic generation
  arm64/sysreg: Convert ID_AA64ISAR1_EL1 to automatic generation
  arm64/sysreg: Convert GMID to automatic generation
  arm64/sysreg: Convert DCZID_EL0 to automatic generation
  arm64/sysreg: Convert CTR_EL0 to automatic generation
  arm64/sysreg: Add _EL1 into ID_AA64ISAR2_EL1 definition names
  arm64/sysreg: Add _EL1 into ID_AA64ISAR1_EL1 definition names
  arm64/sysreg: Remove defines for RPRES enumeration
  arm64/sysreg: Standardise naming for ID_AA64ZFR0_EL1 fields
  arm64/sysreg: Standardise naming for ID_AA64SMFR0_EL1 enums
  arm64/sysreg: Standardise naming for WFxT defines
  arm64/sysreg: Make BHB clear feature defines match the architecture
  arm64/sysreg: Align pointer auth enumeration defines with architecture
  ...

arm64/hwcap: Support FEAT_EBF16

2022-07-20T10:18:11+00:00

The v9.2 feature FEAT_EBF16 provides support for an extended BFloat16 mode.
Allow userspace to discover system support for this feature by adding a
hwcap for it.

Signed-off-by: Mark Brown 
Reviewed-by: Catalin Marinas 
Link: https://lore.kernel.org/r/20220707103632.12745-4-broonie@kernel.org
Signed-off-by: Will Deacon

arm64/sysreg: Standardise naming for CTR_EL0 fields

2022-07-05T10:45:45+00:00

cache.h contains some defines which are used to represent fields and
enumeration values which do not follow the standard naming convention used for
when we automatically generate defines for system registers. Update the
names of the constants to reflect standardised naming and move them to
sysreg.h.

There is also a helper CTR_L1IP() which was open coded and has been
converted to use SYS_FIELD_GET().

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20220704170302.2609529-7-broonie@kernel.org
Signed-off-by: Will Deacon

arm64/cpuinfo: Remove references to reserved cache type

2022-07-05T10:45:45+00:00

In 155433cb365ee466 ("arm64: cache: Remove support for ASID-tagged VIVT
I-caches") we removed all the support fir AIVIVT cache types and renamed
all references to the field to say "unknown" since support for AIVIVT
caches was removed from the architecture. Some confusion has resulted since
the corresponding change to the architecture left the value named as
AIVIVT but documented it as reserved in v8, refactor the code so we don't
define the constant instead. This will help with automatic generation of
this register field since it means we care less about the correspondence
with the ARM.

No functional change, the value displayed to userspace is unchanged.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20220704170302.2609529-2-broonie@kernel.org
Signed-off-by: Will Deacon

arm64/sme: Expose SMIDR through sysfs

2022-06-23T17:22:44+00:00

We currently expose MIDR and REVID to userspace through sysfs to enable it
to make decisions based on the specific implementation. Since SME supports
implementations where streaming mode is provided by a separate hardware
unit called a SMCU it provides a similar ID register SMIDR. Expose it to
userspace via sysfs when the system supports SME along with the other ID
registers.

Since we disable the SME priority mapping feature if it is supported by
hardware we currently mask out the SMPS bit which reports that it is
supported.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20220607132857.1358361-1-broonie@kernel.org
Signed-off-by: Will Deacon

Merge branch kvm-arm64/wfxt into kvmarm-master/next

2022-05-04T08:42:16+00:00

* kvm-arm64/wfxt:
  : .
  : Add support for the WFET/WFIT instructions that provide the same
  : service as WFE/WFI, only with a timeout.
  : .
  KVM: arm64: Expose the WFXT feature to guests
  KVM: arm64: Offer early resume for non-blocking WFxT instructions
  KVM: arm64: Handle blocking WFIT instruction
  KVM: arm64: Introduce kvm_counter_compute_delta() helper
  KVM: arm64: Simplify kvm_cpu_has_pending_timer()
  arm64: Use WFxT for __delay() when possible
  arm64: Add wfet()/wfit() helpers
  arm64: Add HWCAP advertising FEAT_WFXT
  arm64: Add RV and RN fields for ESR_ELx_WFx_ISS
  arm64: Expand ESR_ELx_WFx_ISS_TI to match its ARMv8.7 definition

Signed-off-by: Marc Zyngier

arm64/sme: Identify supported SME vector lengths at boot

2022-04-22T17:50:51+00:00

The vector lengths used for SME are controlled through a similar set of
registers to those for SVE and enumerated using a similar algorithm with
some slight differences due to the fact that unlike SVE there are no
restrictions on which combinations of vector lengths can be supported
nor any mandatory vector lengths which must be implemented.  Add a new
vector type and implement support for enumerating it.

One slightly awkward feature is that we need to read the current vector
length using a different instruction (or enter streaming mode which
would have the same issue and be higher cost).  Rather than add an ops
structure we add special cases directly in the otherwise generic
vec_probe_vqs() function, this is a bit inelegant but it's the only
place where this is an issue.

Signed-off-by: Mark Brown 
Reviewed-by: Catalin Marinas 
Link: https://lore.kernel.org/r/20220419112247.711548-10-broonie@kernel.org
Signed-off-by: Catalin Marinas

arm64/sme: Basic enumeration support

2022-04-22T17:50:49+00:00

This patch introduces basic cpufeature support for discovering the presence
of the Scalable Matrix Extension.

Signed-off-by: Mark Brown 
Reviewed-by: Catalin Marinas 
Link: https://lore.kernel.org/r/20220419112247.711548-9-broonie@kernel.org
Signed-off-by: Catalin Marinas