* [PATCH v3 0/7] arm64: Initial support for CVADP
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
ARMv8.5 introduces a DC CVADP instruction which cleans the data cache to
the point of deep persistence. This series makes the instruction
available to userspace and advertises the presence of this CPU feature.
At present when CONFIG_ARM64_PMEM is enabled and the CVAP feature is
present (ARMv8.2) the CVAP instruction is used (from memcpy_flushcache
and arch_wb_cache_pmem). No changes have been made to use CVADP in
these functions or similar.
As we have moved beyond 32 capabilities we now begin using AT_HWCAP2
for userspace.
Tested as follows:
$ dmesg | grep "Deep"
[ 0.166496] CPU features: detected: Data cache clean to Point of Deep Persistence
$ LD_SHOW_AUXV=1 sleep 2>&1 | grep AT_HWCAP
AT_HWCAP: ef91ff87
AT_HWCAP2: 0x1
Changes since v2:
- Rebased onto v5.1-rc2
- Renamed cpu_{have,set}_feature_name to cpu_{have,set}_named_feature
- Add additional comments and update kernel Documentation
Changes since v1:
- Rebased onto v5.0-rc7
- Introduced cpu_{have,set}_feature_name to eliminate use of
KERNEL_HWCAP prefix
- Hard coded MAX_CPU_FEATURES and added a WARN_ON
- Minor comment and tab/spacing changes
- Use elf_hwcap for all 64 caps in the kernel instead of
a new elf_hwcap2
Andrew Murray (7):
arm64: Handle trapped DC CVADP
arm64: HWCAP: add support for AT_HWCAP2
arm64: HWCAP: encapsulate elf_hwcap
arm64: Expose DC CVADP to userspace
arm64: add CVADP support to the cache maintenance helper
arm64: Advertise ARM64_HAS_DCPODP cpu feature
arm64: docs: document AT_HWCAP2 and unused AT_HWCAP bits
Documentation/arm64/elf_hwcaps.txt | 18 +++-
arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
arch/arm64/crypto/chacha-neon-glue.c | 2 +-
arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
arch/arm64/crypto/ghash-ce-glue.c | 8 +-
arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/crypto/sha256-glue.c | 4 +-
arch/arm64/include/asm/assembler.h | 4 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/cpufeature.h | 21 ++---
arch/arm64/include/asm/esr.h | 3 +-
arch/arm64/include/asm/hwcap.h | 50 ++++++++++-
arch/arm64/include/uapi/asm/hwcap.h | 7 +-
arch/arm64/kernel/cpufeature.c | 108 +++++++++++++++--------
arch/arm64/kernel/cpuinfo.c | 3 +-
arch/arm64/kernel/fpsimd.c | 4 +-
arch/arm64/kernel/traps.c | 3 +
drivers/clocksource/arm_arch_timer.c | 8 ++
19 files changed, 185 insertions(+), 71 deletions(-)
--
2.21.0
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 0/7] arm64: Initial support for CVADP
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
ARMv8.5 introduces a DC CVADP instruction which cleans the data cache to
the point of deep persistence. This series makes the instruction
available to userspace and advertises the presence of this CPU feature.
At present when CONFIG_ARM64_PMEM is enabled and the CVAP feature is
present (ARMv8.2) the CVAP instruction is used (from memcpy_flushcache
and arch_wb_cache_pmem). No changes have been made to use CVADP in
these functions or similar.
As we have moved beyond 32 capabilities we now begin using AT_HWCAP2
for userspace.
Tested as follows:
$ dmesg | grep "Deep"
[ 0.166496] CPU features: detected: Data cache clean to Point of Deep Persistence
$ LD_SHOW_AUXV=1 sleep 2>&1 | grep AT_HWCAP
AT_HWCAP: ef91ff87
AT_HWCAP2: 0x1
Changes since v2:
- Rebased onto v5.1-rc2
- Renamed cpu_{have,set}_feature_name to cpu_{have,set}_named_feature
- Add additional comments and update kernel Documentation
Changes since v1:
- Rebased onto v5.0-rc7
- Introduced cpu_{have,set}_feature_name to eliminate use of
KERNEL_HWCAP prefix
- Hard coded MAX_CPU_FEATURES and added a WARN_ON
- Minor comment and tab/spacing changes
- Use elf_hwcap for all 64 caps in the kernel instead of
a new elf_hwcap2
Andrew Murray (7):
arm64: Handle trapped DC CVADP
arm64: HWCAP: add support for AT_HWCAP2
arm64: HWCAP: encapsulate elf_hwcap
arm64: Expose DC CVADP to userspace
arm64: add CVADP support to the cache maintenance helper
arm64: Advertise ARM64_HAS_DCPODP cpu feature
arm64: docs: document AT_HWCAP2 and unused AT_HWCAP bits
Documentation/arm64/elf_hwcaps.txt | 18 +++-
arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
arch/arm64/crypto/chacha-neon-glue.c | 2 +-
arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
arch/arm64/crypto/ghash-ce-glue.c | 8 +-
arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/crypto/sha256-glue.c | 4 +-
arch/arm64/include/asm/assembler.h | 4 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/cpufeature.h | 21 ++---
arch/arm64/include/asm/esr.h | 3 +-
arch/arm64/include/asm/hwcap.h | 50 ++++++++++-
arch/arm64/include/uapi/asm/hwcap.h | 7 +-
arch/arm64/kernel/cpufeature.c | 108 +++++++++++++++--------
arch/arm64/kernel/cpuinfo.c | 3 +-
arch/arm64/kernel/fpsimd.c | 4 +-
arch/arm64/kernel/traps.c | 3 +
drivers/clocksource/arm_arch_timer.c | 8 ++
19 files changed, 185 insertions(+), 71 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/7] arm64: Handle trapped DC CVADP
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
The ARMv8.5 DC CVADP instruction may be trapped to EL1 via
SCTLR_EL1.UCI therefore let's provide a handler for it.
Just like the CVAP instruction we use a 'sys' instruction instead of
the 'dc' alias to avoid build issues with older toolchains.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/include/asm/esr.h | 3 ++-
arch/arm64/kernel/traps.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 52233f00d53d..07d5c026a0b3 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -198,9 +198,10 @@
/*
* User space cache operations have the following sysreg encoding
* in System instructions.
- * op0=1, op1=3, op2=1, crn=7, crm={ 5, 10, 11, 12, 14 }, WRITE (L=0)
+ * op0=1, op1=3, op2=1, crn=7, crm={ 5, 10, 11, 12, 13, 14 }, WRITE (L=0)
*/
#define ESR_ELx_SYS64_ISS_CRM_DC_CIVAC 14
+#define ESR_ELx_SYS64_ISS_CRM_DC_CVADP 13
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAP 12
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAU 11
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAC 10
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 8ad119c3f665..f66e1ddbe4a7 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -459,6 +459,9 @@ static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
case ESR_ELx_SYS64_ISS_CRM_DC_CVAC: /* DC CVAC, gets promoted */
__user_cache_maint("dc civac", address, ret);
break;
+ case ESR_ELx_SYS64_ISS_CRM_DC_CVADP: /* DC CVADP */
+ __user_cache_maint("sys 3, c7, c13, 1", address, ret);
+ break;
case ESR_ELx_SYS64_ISS_CRM_DC_CVAP: /* DC CVAP */
__user_cache_maint("sys 3, c7, c12, 1", address, ret);
break;
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 1/7] arm64: Handle trapped DC CVADP
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
The ARMv8.5 DC CVADP instruction may be trapped to EL1 via
SCTLR_EL1.UCI therefore let's provide a handler for it.
Just like the CVAP instruction we use a 'sys' instruction instead of
the 'dc' alias to avoid build issues with older toolchains.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/include/asm/esr.h | 3 ++-
arch/arm64/kernel/traps.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 52233f00d53d..07d5c026a0b3 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -198,9 +198,10 @@
/*
* User space cache operations have the following sysreg encoding
* in System instructions.
- * op0=1, op1=3, op2=1, crn=7, crm={ 5, 10, 11, 12, 14 }, WRITE (L=0)
+ * op0=1, op1=3, op2=1, crn=7, crm={ 5, 10, 11, 12, 13, 14 }, WRITE (L=0)
*/
#define ESR_ELx_SYS64_ISS_CRM_DC_CIVAC 14
+#define ESR_ELx_SYS64_ISS_CRM_DC_CVADP 13
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAP 12
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAU 11
#define ESR_ELx_SYS64_ISS_CRM_DC_CVAC 10
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 8ad119c3f665..f66e1ddbe4a7 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -459,6 +459,9 @@ static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
case ESR_ELx_SYS64_ISS_CRM_DC_CVAC: /* DC CVAC, gets promoted */
__user_cache_maint("dc civac", address, ret);
break;
+ case ESR_ELx_SYS64_ISS_CRM_DC_CVADP: /* DC CVADP */
+ __user_cache_maint("sys 3, c7, c13, 1", address, ret);
+ break;
case ESR_ELx_SYS64_ISS_CRM_DC_CVAP: /* DC CVAP */
__user_cache_maint("sys 3, c7, c12, 1", address, ret);
break;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Szabolcs Nagy, dave.martin, linux-arm-kernel, Mark Rutland,
Phil Blundell, libc-alpha, linux-api
As we will exhaust the first 32 bits of AT_HWCAP let's start
exposing AT_HWCAP2 to userspace to give us up to 64 caps.
Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
prefer to expand into AT_HWCAP2 in order to provide a consistent
view to userspace between ILP32 and LP64. However internal to the
kernel we prefer to continue to use the full space of elf_hwcap.
To reduce complexity and allow for future expansion, we now
represent hwcaps in the kernel as ordinals and use a
KERNEL_HWCAP_ prefix. This allows us to support automatic feature
based module loading for all our hwcaps.
We introduce cpu_set_feature to set hwcaps which compliments the
existing cpu_have_feature helper. These helpers allow us to clean
up existing direct uses of elf_hwcap and reduce any future effort
required to move beyond 64 caps.
For convenience we also introduce cpu_{have,set}_named_feature which
makes use of the cpu_feature macro to allow providing a hwcap name
without a {KERNEL_}HWCAP_ prefix.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
arch/arm64/crypto/chacha-neon-glue.c | 2 +-
arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
arch/arm64/crypto/ghash-ce-glue.c | 8 +--
arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/crypto/sha256-glue.c | 4 +-
arch/arm64/include/asm/cpufeature.h | 22 ++++----
arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
arch/arm64/include/uapi/asm/hwcap.h | 2 +-
arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
arch/arm64/kernel/cpuinfo.c | 2 +-
arch/arm64/kernel/fpsimd.c | 4 +-
drivers/clocksource/arm_arch_timer.c | 8 +++
14 files changed, 117 insertions(+), 60 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index 5fc6f51908fd..036ea77f83bc 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -372,7 +372,7 @@ static struct aead_alg ccm_aes_alg = {
static int __init aes_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_AES))
+ if (!cpu_have_named_feature(AES))
return -ENODEV;
return crypto_register_aead(&ccm_aes_alg);
}
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
index e7a95a566462..bf1b321ff4c1 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -440,7 +440,7 @@ static int __init aes_init(void)
int err;
int i;
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
err = crypto_register_skciphers(aes_algs, ARRAY_SIZE(aes_algs));
diff --git a/arch/arm64/crypto/chacha-neon-glue.c b/arch/arm64/crypto/chacha-neon-glue.c
index bece1d85bd81..cb054f51c917 100644
--- a/arch/arm64/crypto/chacha-neon-glue.c
+++ b/arch/arm64/crypto/chacha-neon-glue.c
@@ -173,7 +173,7 @@ static struct skcipher_alg algs[] = {
static int __init chacha_simd_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
return crypto_register_skciphers(algs, ARRAY_SIZE(algs));
diff --git a/arch/arm64/crypto/crct10dif-ce-glue.c b/arch/arm64/crypto/crct10dif-ce-glue.c
index dd325829ee44..e81d5bd555c0 100644
--- a/arch/arm64/crypto/crct10dif-ce-glue.c
+++ b/arch/arm64/crypto/crct10dif-ce-glue.c
@@ -101,7 +101,7 @@ static struct shash_alg crc_t10dif_alg[] = {{
static int __init crc_t10dif_mod_init(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
return crypto_register_shashes(crc_t10dif_alg,
ARRAY_SIZE(crc_t10dif_alg));
else
@@ -111,7 +111,7 @@ static int __init crc_t10dif_mod_init(void)
static void __exit crc_t10dif_mod_exit(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
crypto_unregister_shashes(crc_t10dif_alg,
ARRAY_SIZE(crc_t10dif_alg));
else
diff --git a/arch/arm64/crypto/ghash-ce-glue.c b/arch/arm64/crypto/ghash-ce-glue.c
index 791ad422c427..4e69bb78ea89 100644
--- a/arch/arm64/crypto/ghash-ce-glue.c
+++ b/arch/arm64/crypto/ghash-ce-glue.c
@@ -704,10 +704,10 @@ static int __init ghash_ce_mod_init(void)
{
int ret;
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
ret = crypto_register_shashes(ghash_alg,
ARRAY_SIZE(ghash_alg));
else
@@ -717,7 +717,7 @@ static int __init ghash_ce_mod_init(void)
if (ret)
return ret;
- if (elf_hwcap & HWCAP_PMULL) {
+ if (cpu_have_named_feature(PMULL)) {
ret = crypto_register_aead(&gcm_aes_alg);
if (ret)
crypto_unregister_shashes(ghash_alg,
@@ -728,7 +728,7 @@ static int __init ghash_ce_mod_init(void)
static void __exit ghash_ce_mod_exit(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
crypto_unregister_shashes(ghash_alg, ARRAY_SIZE(ghash_alg));
else
crypto_unregister_shash(ghash_alg);
diff --git a/arch/arm64/crypto/nhpoly1305-neon-glue.c b/arch/arm64/crypto/nhpoly1305-neon-glue.c
index 22cc32ac9448..38a589044b6c 100644
--- a/arch/arm64/crypto/nhpoly1305-neon-glue.c
+++ b/arch/arm64/crypto/nhpoly1305-neon-glue.c
@@ -56,7 +56,7 @@ static struct shash_alg nhpoly1305_alg = {
static int __init nhpoly1305_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
return crypto_register_shash(&nhpoly1305_alg);
diff --git a/arch/arm64/crypto/sha256-glue.c b/arch/arm64/crypto/sha256-glue.c
index 4aedeaefd61f..0cccdb9cc2c0 100644
--- a/arch/arm64/crypto/sha256-glue.c
+++ b/arch/arm64/crypto/sha256-glue.c
@@ -173,7 +173,7 @@ static int __init sha256_mod_init(void)
if (ret)
return ret;
- if (elf_hwcap & HWCAP_ASIMD) {
+ if (cpu_have_named_feature(ASIMD)) {
ret = crypto_register_shashes(neon_algs, ARRAY_SIZE(neon_algs));
if (ret)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
@@ -183,7 +183,7 @@ static int __init sha256_mod_init(void)
static void __exit sha256_mod_fini(void)
{
- if (elf_hwcap & HWCAP_ASIMD)
+ if (cpu_have_named_feature(ASIMD))
crypto_unregister_shashes(neon_algs, ARRAY_SIZE(neon_algs));
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index e505e1fbd2b9..f06e1da1d678 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -14,15 +14,8 @@
#include <asm/hwcap.h>
#include <asm/sysreg.h>
-/*
- * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
- * in the kernel and for user space to keep track of which optional features
- * are supported by the current system. So let's map feature 'x' to HWCAP_x.
- * Note that HWCAP_x constants are bit fields so we need to take the log.
- */
-
-#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
-#define cpu_feature(x) ilog2(HWCAP_ ## x)
+#define MAX_CPU_FEATURES 64
+#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
#ifndef __ASSEMBLY__
@@ -400,10 +393,19 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
bool this_cpu_has_cap(unsigned int cap);
+static inline void cpu_set_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ elf_hwcap |= BIT(num);
+}
+#define cpu_set_named_feature(name) cpu_set_feature(cpu_feature(name))
+
static inline bool cpu_have_feature(unsigned int num)
{
- return elf_hwcap & (1UL << num);
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ return elf_hwcap & BIT(num);
}
+#define cpu_have_named_feature(name) cpu_have_feature(cpu_feature(name))
/* System capability check for constant caps */
static inline bool __cpus_have_const_cap(int num)
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 400b80b49595..d21fe3314d90 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -39,12 +39,59 @@
#define COMPAT_HWCAP2_SHA2 (1 << 3)
#define COMPAT_HWCAP2_CRC32 (1 << 4)
+/*
+ * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
+ * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
+ * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
+ * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
+ *
+ * Hwcaps should be set and tested within the kernel via the
+ * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
+ * of KERNEL_HWCAP_{feature}.
+ */
+#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
+#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
+#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
+#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
+#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
+#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
+#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
+#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
+#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
+#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
+#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
+#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
+#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
+#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
+#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
+#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
+#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
+#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
+#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
+#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
+#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
+#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
+#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
+#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
+#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
+#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
+#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
+#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
+#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
+#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
+#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
+#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
+#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
+
#ifndef __ASSEMBLY__
+#include <linux/kernel.h>
+
/*
* This yields a mask that user programs can use to figure out what
* instruction set this cpu supports.
*/
-#define ELF_HWCAP (elf_hwcap)
+#define ELF_HWCAP lower_32_bits(elf_hwcap)
+#define ELF_HWCAP2 upper_32_bits(elf_hwcap)
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 5f0750c2199c..453b45af80b7 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -18,7 +18,7 @@
#define _UAPI__ASM_HWCAP_H
/*
- * HWCAP flags - for elf_hwcap (in kernel) and AT_HWCAP
+ * HWCAP flags - for AT_HWCAP
*/
#define HWCAP_FP (1 << 0)
#define HWCAP_ASIMD (1 << 1)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4061de10cea6..986ceeacd19f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1571,39 +1571,39 @@ static const struct arm64_cpu_capabilities ptr_auth_hwcap_gen_matches[] = {
#endif
static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_PMULL),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_AES),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA1),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA2),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_SHA512),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_CRC32),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ATOMICS),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDRDM),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA3),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_FLAGM),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_ASIMDHP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_DIT),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_DCPOP),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_JSCVT),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_FCMA),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_LRCPC),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ILRCPC),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_SB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SB),
- HWCAP_CAP(SYS_ID_AA64MMFR2_EL1, ID_AA64MMFR2_AT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_USCAT),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_FP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FPHP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_ASIMD),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDHP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DIT),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DCPOP),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_JSCVT),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FCMA),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_LRCPC),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ILRCPC),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_SB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SB),
+ HWCAP_CAP(SYS_ID_AA64MMFR2_EL1, ID_AA64MMFR2_AT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_USCAT),
#ifdef CONFIG_ARM64_SVE
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, ID_AA64PFR0_SVE, CAP_HWCAP, HWCAP_SVE),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, ID_AA64PFR0_SVE, CAP_HWCAP, KERNEL_HWCAP_SVE),
#endif
- HWCAP_CAP(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_SSBS_SHIFT, FTR_UNSIGNED, ID_AA64PFR1_SSBS_PSTATE_INSNS, CAP_HWCAP, HWCAP_SSBS),
+ HWCAP_CAP(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_SSBS_SHIFT, FTR_UNSIGNED, ID_AA64PFR1_SSBS_PSTATE_INSNS, CAP_HWCAP, KERNEL_HWCAP_SSBS),
#ifdef CONFIG_ARM64_PTR_AUTH
- HWCAP_MULTI_CAP(ptr_auth_hwcap_addr_matches, CAP_HWCAP, HWCAP_PACA),
- HWCAP_MULTI_CAP(ptr_auth_hwcap_gen_matches, CAP_HWCAP, HWCAP_PACG),
+ HWCAP_MULTI_CAP(ptr_auth_hwcap_addr_matches, CAP_HWCAP, KERNEL_HWCAP_PACA),
+ HWCAP_MULTI_CAP(ptr_auth_hwcap_gen_matches, CAP_HWCAP, KERNEL_HWCAP_PACG),
#endif
{},
};
@@ -1623,7 +1623,7 @@ static void __init cap_set_elf_hwcap(const struct arm64_cpu_capabilities *cap)
{
switch (cap->hwcap_type) {
case CAP_HWCAP:
- elf_hwcap |= cap->hwcap;
+ cpu_set_feature(cap->hwcap);
break;
#ifdef CONFIG_COMPAT
case CAP_COMPAT_HWCAP:
@@ -1646,7 +1646,7 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
switch (cap->hwcap_type) {
case CAP_HWCAP:
- rc = (elf_hwcap & cap->hwcap) != 0;
+ rc = cpu_have_feature(cap->hwcap);
break;
#ifdef CONFIG_COMPAT
case CAP_COMPAT_HWCAP:
@@ -1667,7 +1667,7 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
{
/* We support emulation of accesses to CPU ID feature registers */
- elf_hwcap |= HWCAP_CPUID;
+ cpu_set_named_feature(CPUID);
for (; hwcaps->matches; hwcaps++)
if (hwcaps->matches(hwcaps, cpucap_default_scope(hwcaps)))
cap_set_elf_hwcap(hwcaps);
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index ca0685f33900..810db95f293f 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -167,7 +167,7 @@ static int c_show(struct seq_file *m, void *v)
#endif /* CONFIG_COMPAT */
} else {
for (j = 0; hwcap_str[j]; j++)
- if (elf_hwcap & (1 << j))
+ if (cpu_have_feature(j))
seq_printf(m, " %s", hwcap_str[j]);
}
seq_puts(m, "\n");
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5ebe73b69961..735cf1f8b109 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1258,14 +1258,14 @@ static inline void fpsimd_hotplug_init(void) { }
*/
static int __init fpsimd_init(void)
{
- if (elf_hwcap & HWCAP_FP) {
+ if (cpu_have_named_feature(FP)) {
fpsimd_pm_init();
fpsimd_hotplug_init();
} else {
pr_notice("Floating-point is not implemented\n");
}
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
pr_notice("Advanced SIMD is not implemented\n");
return sve_sysctl_init();
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index aa4ec53281ce..6cc8aff83805 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
| ARCH_TIMER_VIRT_EVT_EN;
arch_timer_set_cntkctl(cntkctl);
+#ifdef CONFIG_ARM64
+ cpu_set_named_feature(EVTSTRM);
+#else
elf_hwcap |= HWCAP_EVTSTRM;
+#endif
#ifdef CONFIG_COMPAT
compat_elf_hwcap |= COMPAT_HWCAP_EVTSTRM;
#endif
@@ -1055,7 +1059,11 @@ static int arch_timer_cpu_pm_notify(struct notifier_block *self,
} else if (action == CPU_PM_ENTER_FAILED || action == CPU_PM_EXIT) {
arch_timer_set_cntkctl(__this_cpu_read(saved_cntkctl));
+#ifdef CONFIG_ARM64
+ if (cpu_have_named_feature(EVTSTRM))
+#else
if (elf_hwcap & HWCAP_EVTSTRM)
+#endif
cpumask_set_cpu(smp_processor_id(), &evtstrm_available);
}
return NOTIFY_OK;
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
As we will exhaust the first 32 bits of AT_HWCAP let's start
exposing AT_HWCAP2 to userspace to give us up to 64 caps.
Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
prefer to expand into AT_HWCAP2 in order to provide a consistent
view to userspace between ILP32 and LP64. However internal to the
kernel we prefer to continue to use the full space of elf_hwcap.
To reduce complexity and allow for future expansion, we now
represent hwcaps in the kernel as ordinals and use a
KERNEL_HWCAP_ prefix. This allows us to support automatic feature
based module loading for all our hwcaps.
We introduce cpu_set_feature to set hwcaps which compliments the
existing cpu_have_feature helper. These helpers allow us to clean
up existing direct uses of elf_hwcap and reduce any future effort
required to move beyond 64 caps.
For convenience we also introduce cpu_{have,set}_named_feature which
makes use of the cpu_feature macro to allow providing a hwcap name
without a {KERNEL_}HWCAP_ prefix.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
arch/arm64/crypto/chacha-neon-glue.c | 2 +-
arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
arch/arm64/crypto/ghash-ce-glue.c | 8 +--
arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/crypto/sha256-glue.c | 4 +-
arch/arm64/include/asm/cpufeature.h | 22 ++++----
arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
arch/arm64/include/uapi/asm/hwcap.h | 2 +-
arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
arch/arm64/kernel/cpuinfo.c | 2 +-
arch/arm64/kernel/fpsimd.c | 4 +-
drivers/clocksource/arm_arch_timer.c | 8 +++
14 files changed, 117 insertions(+), 60 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index 5fc6f51908fd..036ea77f83bc 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -372,7 +372,7 @@ static struct aead_alg ccm_aes_alg = {
static int __init aes_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_AES))
+ if (!cpu_have_named_feature(AES))
return -ENODEV;
return crypto_register_aead(&ccm_aes_alg);
}
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
index e7a95a566462..bf1b321ff4c1 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -440,7 +440,7 @@ static int __init aes_init(void)
int err;
int i;
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
err = crypto_register_skciphers(aes_algs, ARRAY_SIZE(aes_algs));
diff --git a/arch/arm64/crypto/chacha-neon-glue.c b/arch/arm64/crypto/chacha-neon-glue.c
index bece1d85bd81..cb054f51c917 100644
--- a/arch/arm64/crypto/chacha-neon-glue.c
+++ b/arch/arm64/crypto/chacha-neon-glue.c
@@ -173,7 +173,7 @@ static struct skcipher_alg algs[] = {
static int __init chacha_simd_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
return crypto_register_skciphers(algs, ARRAY_SIZE(algs));
diff --git a/arch/arm64/crypto/crct10dif-ce-glue.c b/arch/arm64/crypto/crct10dif-ce-glue.c
index dd325829ee44..e81d5bd555c0 100644
--- a/arch/arm64/crypto/crct10dif-ce-glue.c
+++ b/arch/arm64/crypto/crct10dif-ce-glue.c
@@ -101,7 +101,7 @@ static struct shash_alg crc_t10dif_alg[] = {{
static int __init crc_t10dif_mod_init(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
return crypto_register_shashes(crc_t10dif_alg,
ARRAY_SIZE(crc_t10dif_alg));
else
@@ -111,7 +111,7 @@ static int __init crc_t10dif_mod_init(void)
static void __exit crc_t10dif_mod_exit(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
crypto_unregister_shashes(crc_t10dif_alg,
ARRAY_SIZE(crc_t10dif_alg));
else
diff --git a/arch/arm64/crypto/ghash-ce-glue.c b/arch/arm64/crypto/ghash-ce-glue.c
index 791ad422c427..4e69bb78ea89 100644
--- a/arch/arm64/crypto/ghash-ce-glue.c
+++ b/arch/arm64/crypto/ghash-ce-glue.c
@@ -704,10 +704,10 @@ static int __init ghash_ce_mod_init(void)
{
int ret;
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
ret = crypto_register_shashes(ghash_alg,
ARRAY_SIZE(ghash_alg));
else
@@ -717,7 +717,7 @@ static int __init ghash_ce_mod_init(void)
if (ret)
return ret;
- if (elf_hwcap & HWCAP_PMULL) {
+ if (cpu_have_named_feature(PMULL)) {
ret = crypto_register_aead(&gcm_aes_alg);
if (ret)
crypto_unregister_shashes(ghash_alg,
@@ -728,7 +728,7 @@ static int __init ghash_ce_mod_init(void)
static void __exit ghash_ce_mod_exit(void)
{
- if (elf_hwcap & HWCAP_PMULL)
+ if (cpu_have_named_feature(PMULL))
crypto_unregister_shashes(ghash_alg, ARRAY_SIZE(ghash_alg));
else
crypto_unregister_shash(ghash_alg);
diff --git a/arch/arm64/crypto/nhpoly1305-neon-glue.c b/arch/arm64/crypto/nhpoly1305-neon-glue.c
index 22cc32ac9448..38a589044b6c 100644
--- a/arch/arm64/crypto/nhpoly1305-neon-glue.c
+++ b/arch/arm64/crypto/nhpoly1305-neon-glue.c
@@ -56,7 +56,7 @@ static struct shash_alg nhpoly1305_alg = {
static int __init nhpoly1305_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
return -ENODEV;
return crypto_register_shash(&nhpoly1305_alg);
diff --git a/arch/arm64/crypto/sha256-glue.c b/arch/arm64/crypto/sha256-glue.c
index 4aedeaefd61f..0cccdb9cc2c0 100644
--- a/arch/arm64/crypto/sha256-glue.c
+++ b/arch/arm64/crypto/sha256-glue.c
@@ -173,7 +173,7 @@ static int __init sha256_mod_init(void)
if (ret)
return ret;
- if (elf_hwcap & HWCAP_ASIMD) {
+ if (cpu_have_named_feature(ASIMD)) {
ret = crypto_register_shashes(neon_algs, ARRAY_SIZE(neon_algs));
if (ret)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
@@ -183,7 +183,7 @@ static int __init sha256_mod_init(void)
static void __exit sha256_mod_fini(void)
{
- if (elf_hwcap & HWCAP_ASIMD)
+ if (cpu_have_named_feature(ASIMD))
crypto_unregister_shashes(neon_algs, ARRAY_SIZE(neon_algs));
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index e505e1fbd2b9..f06e1da1d678 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -14,15 +14,8 @@
#include <asm/hwcap.h>
#include <asm/sysreg.h>
-/*
- * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
- * in the kernel and for user space to keep track of which optional features
- * are supported by the current system. So let's map feature 'x' to HWCAP_x.
- * Note that HWCAP_x constants are bit fields so we need to take the log.
- */
-
-#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
-#define cpu_feature(x) ilog2(HWCAP_ ## x)
+#define MAX_CPU_FEATURES 64
+#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
#ifndef __ASSEMBLY__
@@ -400,10 +393,19 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
bool this_cpu_has_cap(unsigned int cap);
+static inline void cpu_set_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ elf_hwcap |= BIT(num);
+}
+#define cpu_set_named_feature(name) cpu_set_feature(cpu_feature(name))
+
static inline bool cpu_have_feature(unsigned int num)
{
- return elf_hwcap & (1UL << num);
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ return elf_hwcap & BIT(num);
}
+#define cpu_have_named_feature(name) cpu_have_feature(cpu_feature(name))
/* System capability check for constant caps */
static inline bool __cpus_have_const_cap(int num)
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 400b80b49595..d21fe3314d90 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -39,12 +39,59 @@
#define COMPAT_HWCAP2_SHA2 (1 << 3)
#define COMPAT_HWCAP2_CRC32 (1 << 4)
+/*
+ * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
+ * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
+ * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
+ * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
+ *
+ * Hwcaps should be set and tested within the kernel via the
+ * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
+ * of KERNEL_HWCAP_{feature}.
+ */
+#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
+#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
+#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
+#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
+#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
+#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
+#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
+#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
+#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
+#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
+#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
+#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
+#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
+#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
+#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
+#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
+#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
+#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
+#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
+#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
+#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
+#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
+#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
+#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
+#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
+#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
+#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
+#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
+#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
+#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
+#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
+#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
+#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
+
#ifndef __ASSEMBLY__
+#include <linux/kernel.h>
+
/*
* This yields a mask that user programs can use to figure out what
* instruction set this cpu supports.
*/
-#define ELF_HWCAP (elf_hwcap)
+#define ELF_HWCAP lower_32_bits(elf_hwcap)
+#define ELF_HWCAP2 upper_32_bits(elf_hwcap)
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 5f0750c2199c..453b45af80b7 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -18,7 +18,7 @@
#define _UAPI__ASM_HWCAP_H
/*
- * HWCAP flags - for elf_hwcap (in kernel) and AT_HWCAP
+ * HWCAP flags - for AT_HWCAP
*/
#define HWCAP_FP (1 << 0)
#define HWCAP_ASIMD (1 << 1)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4061de10cea6..986ceeacd19f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1571,39 +1571,39 @@ static const struct arm64_cpu_capabilities ptr_auth_hwcap_gen_matches[] = {
#endif
static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_PMULL),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_AES),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA1),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA2),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_SHA512),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_CRC32),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ATOMICS),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDRDM),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA3),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
- HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_FLAGM),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_ASIMDHP),
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_DIT),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_DCPOP),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_JSCVT),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_FCMA),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_LRCPC),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ILRCPC),
- HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_SB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SB),
- HWCAP_CAP(SYS_ID_AA64MMFR2_EL1, ID_AA64MMFR2_AT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_USCAT),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_FP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FPHP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_ASIMD),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDHP),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DIT),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DCPOP),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_JSCVT),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FCMA),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_LRCPC),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ILRCPC),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_SB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SB),
+ HWCAP_CAP(SYS_ID_AA64MMFR2_EL1, ID_AA64MMFR2_AT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_USCAT),
#ifdef CONFIG_ARM64_SVE
- HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, ID_AA64PFR0_SVE, CAP_HWCAP, HWCAP_SVE),
+ HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, ID_AA64PFR0_SVE, CAP_HWCAP, KERNEL_HWCAP_SVE),
#endif
- HWCAP_CAP(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_SSBS_SHIFT, FTR_UNSIGNED, ID_AA64PFR1_SSBS_PSTATE_INSNS, CAP_HWCAP, HWCAP_SSBS),
+ HWCAP_CAP(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_SSBS_SHIFT, FTR_UNSIGNED, ID_AA64PFR1_SSBS_PSTATE_INSNS, CAP_HWCAP, KERNEL_HWCAP_SSBS),
#ifdef CONFIG_ARM64_PTR_AUTH
- HWCAP_MULTI_CAP(ptr_auth_hwcap_addr_matches, CAP_HWCAP, HWCAP_PACA),
- HWCAP_MULTI_CAP(ptr_auth_hwcap_gen_matches, CAP_HWCAP, HWCAP_PACG),
+ HWCAP_MULTI_CAP(ptr_auth_hwcap_addr_matches, CAP_HWCAP, KERNEL_HWCAP_PACA),
+ HWCAP_MULTI_CAP(ptr_auth_hwcap_gen_matches, CAP_HWCAP, KERNEL_HWCAP_PACG),
#endif
{},
};
@@ -1623,7 +1623,7 @@ static void __init cap_set_elf_hwcap(const struct arm64_cpu_capabilities *cap)
{
switch (cap->hwcap_type) {
case CAP_HWCAP:
- elf_hwcap |= cap->hwcap;
+ cpu_set_feature(cap->hwcap);
break;
#ifdef CONFIG_COMPAT
case CAP_COMPAT_HWCAP:
@@ -1646,7 +1646,7 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
switch (cap->hwcap_type) {
case CAP_HWCAP:
- rc = (elf_hwcap & cap->hwcap) != 0;
+ rc = cpu_have_feature(cap->hwcap);
break;
#ifdef CONFIG_COMPAT
case CAP_COMPAT_HWCAP:
@@ -1667,7 +1667,7 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
{
/* We support emulation of accesses to CPU ID feature registers */
- elf_hwcap |= HWCAP_CPUID;
+ cpu_set_named_feature(CPUID);
for (; hwcaps->matches; hwcaps++)
if (hwcaps->matches(hwcaps, cpucap_default_scope(hwcaps)))
cap_set_elf_hwcap(hwcaps);
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index ca0685f33900..810db95f293f 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -167,7 +167,7 @@ static int c_show(struct seq_file *m, void *v)
#endif /* CONFIG_COMPAT */
} else {
for (j = 0; hwcap_str[j]; j++)
- if (elf_hwcap & (1 << j))
+ if (cpu_have_feature(j))
seq_printf(m, " %s", hwcap_str[j]);
}
seq_puts(m, "\n");
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5ebe73b69961..735cf1f8b109 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1258,14 +1258,14 @@ static inline void fpsimd_hotplug_init(void) { }
*/
static int __init fpsimd_init(void)
{
- if (elf_hwcap & HWCAP_FP) {
+ if (cpu_have_named_feature(FP)) {
fpsimd_pm_init();
fpsimd_hotplug_init();
} else {
pr_notice("Floating-point is not implemented\n");
}
- if (!(elf_hwcap & HWCAP_ASIMD))
+ if (!cpu_have_named_feature(ASIMD))
pr_notice("Advanced SIMD is not implemented\n");
return sve_sysctl_init();
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index aa4ec53281ce..6cc8aff83805 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
| ARCH_TIMER_VIRT_EVT_EN;
arch_timer_set_cntkctl(cntkctl);
+#ifdef CONFIG_ARM64
+ cpu_set_named_feature(EVTSTRM);
+#else
elf_hwcap |= HWCAP_EVTSTRM;
+#endif
#ifdef CONFIG_COMPAT
compat_elf_hwcap |= COMPAT_HWCAP_EVTSTRM;
#endif
@@ -1055,7 +1059,11 @@ static int arch_timer_cpu_pm_notify(struct notifier_block *self,
} else if (action == CPU_PM_ENTER_FAILED || action == CPU_PM_EXIT) {
arch_timer_set_cntkctl(__this_cpu_read(saved_cntkctl));
+#ifdef CONFIG_ARM64
+ if (cpu_have_named_feature(EVTSTRM))
+#else
if (elf_hwcap & HWCAP_EVTSTRM)
+#endif
cpumask_set_cpu(smp_processor_id(), &evtstrm_available);
}
return NOTIFY_OK;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Szabolcs Nagy, dave.martin, linux-arm-kernel, Mark Rutland,
Phil Blundell, libc-alpha, linux-api
The introduction of AT_HWCAP2 introduced accessors which ensure that
hwcap features are set and tested appropriately.
Let's now mandate access to elf_hwcap via these accessors by making
elf_hwcap static within cpufeature.c.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 15 ++++----------
arch/arm64/include/asm/hwcap.h | 7 +++----
arch/arm64/kernel/cpufeature.c | 32 +++++++++++++++++++++++++++--
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f06e1da1d678..4c766f831de6 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -392,19 +392,12 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
bool this_cpu_has_cap(unsigned int cap);
+void cpu_set_feature(unsigned int num);
+bool cpu_have_feature(unsigned int num);
+unsigned long cpu_get_elf_hwcap(void);
+unsigned long cpu_get_elf_hwcap2(void);
-static inline void cpu_set_feature(unsigned int num)
-{
- WARN_ON(num >= MAX_CPU_FEATURES);
- elf_hwcap |= BIT(num);
-}
#define cpu_set_named_feature(name) cpu_set_feature(cpu_feature(name))
-
-static inline bool cpu_have_feature(unsigned int num)
-{
- WARN_ON(num >= MAX_CPU_FEATURES);
- return elf_hwcap & BIT(num);
-}
#define cpu_have_named_feature(name) cpu_have_feature(cpu_feature(name))
/* System capability check for constant caps */
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index d21fe3314d90..de9a66672ba7 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -17,6 +17,7 @@
#define __ASM_HWCAP_H
#include <uapi/asm/hwcap.h>
+#include <asm/cpufeature.h>
#define COMPAT_HWCAP_HALF (1 << 1)
#define COMPAT_HWCAP_THUMB (1 << 2)
@@ -84,14 +85,13 @@
#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
#ifndef __ASSEMBLY__
-#include <linux/kernel.h>
/*
* This yields a mask that user programs can use to figure out what
* instruction set this cpu supports.
*/
-#define ELF_HWCAP lower_32_bits(elf_hwcap)
-#define ELF_HWCAP2 upper_32_bits(elf_hwcap)
+#define ELF_HWCAP cpu_get_elf_hwcap()
+#define ELF_HWCAP2 cpu_get_elf_hwcap2()
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
@@ -107,6 +107,5 @@ enum {
#endif
};
-extern unsigned long elf_hwcap;
#endif
#endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 986ceeacd19f..84ca52fa75e5 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -35,8 +35,7 @@
#include <asm/traps.h>
#include <asm/virt.h>
-unsigned long elf_hwcap __read_mostly;
-EXPORT_SYMBOL_GPL(elf_hwcap);
+static unsigned long elf_hwcap __read_mostly;
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP_DEFAULT \
@@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
return false;
}
+void cpu_set_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ elf_hwcap |= BIT(num);
+}
+EXPORT_SYMBOL_GPL(cpu_set_feature);
+
+bool cpu_have_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ return elf_hwcap & BIT(num);
+}
+EXPORT_SYMBOL_GPL(cpu_have_feature);
+
+unsigned long cpu_get_elf_hwcap(void)
+{
+ /*
+ * We currently only populate the first 32 bits of AT_HWCAP. Please
+ * note that for userspace compatibility we guarantee that bit 62
+ * will always be returned as 0.
+ */
+ return lower_32_bits(elf_hwcap);
+}
+
+unsigned long cpu_get_elf_hwcap2(void)
+{
+ return upper_32_bits(elf_hwcap);
+}
+
static void __init setup_system_capabilities(void)
{
/*
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
The introduction of AT_HWCAP2 introduced accessors which ensure that
hwcap features are set and tested appropriately.
Let's now mandate access to elf_hwcap via these accessors by making
elf_hwcap static within cpufeature.c.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 15 ++++----------
arch/arm64/include/asm/hwcap.h | 7 +++----
arch/arm64/kernel/cpufeature.c | 32 +++++++++++++++++++++++++++--
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f06e1da1d678..4c766f831de6 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -392,19 +392,12 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
bool this_cpu_has_cap(unsigned int cap);
+void cpu_set_feature(unsigned int num);
+bool cpu_have_feature(unsigned int num);
+unsigned long cpu_get_elf_hwcap(void);
+unsigned long cpu_get_elf_hwcap2(void);
-static inline void cpu_set_feature(unsigned int num)
-{
- WARN_ON(num >= MAX_CPU_FEATURES);
- elf_hwcap |= BIT(num);
-}
#define cpu_set_named_feature(name) cpu_set_feature(cpu_feature(name))
-
-static inline bool cpu_have_feature(unsigned int num)
-{
- WARN_ON(num >= MAX_CPU_FEATURES);
- return elf_hwcap & BIT(num);
-}
#define cpu_have_named_feature(name) cpu_have_feature(cpu_feature(name))
/* System capability check for constant caps */
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index d21fe3314d90..de9a66672ba7 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -17,6 +17,7 @@
#define __ASM_HWCAP_H
#include <uapi/asm/hwcap.h>
+#include <asm/cpufeature.h>
#define COMPAT_HWCAP_HALF (1 << 1)
#define COMPAT_HWCAP_THUMB (1 << 2)
@@ -84,14 +85,13 @@
#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
#ifndef __ASSEMBLY__
-#include <linux/kernel.h>
/*
* This yields a mask that user programs can use to figure out what
* instruction set this cpu supports.
*/
-#define ELF_HWCAP lower_32_bits(elf_hwcap)
-#define ELF_HWCAP2 upper_32_bits(elf_hwcap)
+#define ELF_HWCAP cpu_get_elf_hwcap()
+#define ELF_HWCAP2 cpu_get_elf_hwcap2()
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
@@ -107,6 +107,5 @@ enum {
#endif
};
-extern unsigned long elf_hwcap;
#endif
#endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 986ceeacd19f..84ca52fa75e5 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -35,8 +35,7 @@
#include <asm/traps.h>
#include <asm/virt.h>
-unsigned long elf_hwcap __read_mostly;
-EXPORT_SYMBOL_GPL(elf_hwcap);
+static unsigned long elf_hwcap __read_mostly;
#ifdef CONFIG_COMPAT
#define COMPAT_ELF_HWCAP_DEFAULT \
@@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
return false;
}
+void cpu_set_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ elf_hwcap |= BIT(num);
+}
+EXPORT_SYMBOL_GPL(cpu_set_feature);
+
+bool cpu_have_feature(unsigned int num)
+{
+ WARN_ON(num >= MAX_CPU_FEATURES);
+ return elf_hwcap & BIT(num);
+}
+EXPORT_SYMBOL_GPL(cpu_have_feature);
+
+unsigned long cpu_get_elf_hwcap(void)
+{
+ /*
+ * We currently only populate the first 32 bits of AT_HWCAP. Please
+ * note that for userspace compatibility we guarantee that bit 62
+ * will always be returned as 0.
+ */
+ return lower_32_bits(elf_hwcap);
+}
+
+unsigned long cpu_get_elf_hwcap2(void)
+{
+ return upper_32_bits(elf_hwcap);
+}
+
static void __init setup_system_capabilities(void)
{
/*
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 4/7] arm64: Expose DC CVADP to userspace
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
ARMv8.5 builds upon the ARMv8.2 DC CVAP instruction by introducing a DC
CVADP instruction which cleans the data cache to the point of deep
persistence. Let's expose this support via the arm64 ELF hwcaps.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
Documentation/arm64/elf_hwcaps.txt | 4 ++++
arch/arm64/include/uapi/asm/hwcap.h | 5 +++++
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/cpuinfo.c | 1 +
4 files changed, 11 insertions(+)
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index 13d6691b37be..c605757dd4db 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -135,6 +135,10 @@ HWCAP_DCPOP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
+HWCAP2_DCPODP
+
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
+
HWCAP_SHA3
Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 453b45af80b7..d64af3913a9e 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -53,4 +53,9 @@
#define HWCAP_PACA (1 << 30)
#define HWCAP_PACG (1UL << 31)
+/*
+ * HWCAP2 flags - for AT_HWCAP2
+ */
+#define HWCAP2_DCPODP (1 << 0)
+
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 84ca52fa75e5..5e27d2dbe45e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1590,6 +1590,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DIT),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DCPOP),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_DCPODP),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_JSCVT),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FCMA),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_LRCPC),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 810db95f293f..093ca53ce1d1 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -85,6 +85,7 @@ static const char *const hwcap_str[] = {
"sb",
"paca",
"pacg",
+ "dcpodp",
NULL
};
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 4/7] arm64: Expose DC CVADP to userspace
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
ARMv8.5 builds upon the ARMv8.2 DC CVAP instruction by introducing a DC
CVADP instruction which cleans the data cache to the point of deep
persistence. Let's expose this support via the arm64 ELF hwcaps.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
Documentation/arm64/elf_hwcaps.txt | 4 ++++
arch/arm64/include/uapi/asm/hwcap.h | 5 +++++
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/cpuinfo.c | 1 +
4 files changed, 11 insertions(+)
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index 13d6691b37be..c605757dd4db 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -135,6 +135,10 @@ HWCAP_DCPOP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
+HWCAP2_DCPODP
+
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
+
HWCAP_SHA3
Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 453b45af80b7..d64af3913a9e 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -53,4 +53,9 @@
#define HWCAP_PACA (1 << 30)
#define HWCAP_PACG (1UL << 31)
+/*
+ * HWCAP2 flags - for AT_HWCAP2
+ */
+#define HWCAP2_DCPODP (1 << 0)
+
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 84ca52fa75e5..5e27d2dbe45e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1590,6 +1590,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_DIT_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DIT),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_DCPOP),
+ HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_DPB_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_DCPODP),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_JSCVT_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_JSCVT),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_FCMA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FCMA),
HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_LRCPC_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_LRCPC),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 810db95f293f..093ca53ce1d1 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -85,6 +85,7 @@ static const char *const hwcap_str[] = {
"sb",
"paca",
"pacg",
+ "dcpodp",
NULL
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 5/7] arm64: add CVADP support to the cache maintenance helper
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
Allow users of dcache_by_line_op to specify cvadp as an op.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/assembler.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index c5308d01e228..d50caf0e6b64 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -407,10 +407,14 @@ alternative_endif
.ifc \op, cvap
sys 3, c7, c12, 1, \kaddr // dc cvap
.else
+ .ifc \op, cvadp
+ sys 3, c7, c13, 1, \kaddr // dc cvadp
+ .else
dc \op, \kaddr
.endif
.endif
.endif
+ .endif
add \kaddr, \kaddr, \tmp1
cmp \kaddr, \size
b.lo 9998b
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 5/7] arm64: add CVADP support to the cache maintenance helper
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
Allow users of dcache_by_line_op to specify cvadp as an op.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/assembler.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index c5308d01e228..d50caf0e6b64 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -407,10 +407,14 @@ alternative_endif
.ifc \op, cvap
sys 3, c7, c12, 1, \kaddr // dc cvap
.else
+ .ifc \op, cvadp
+ sys 3, c7, c13, 1, \kaddr // dc cvadp
+ .else
dc \op, \kaddr
.endif
.endif
.endif
+ .endif
add \kaddr, \kaddr, \tmp1
cmp \kaddr, \size
b.lo 9998b
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 9 +++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index f6a76e43f39e..defdc67d9ab4 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -61,7 +61,8 @@
#define ARM64_HAS_GENERIC_AUTH_ARCH 40
#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
#define ARM64_HAS_IRQ_PRIO_MASKING 42
+#define ARM64_HAS_DCPODP 43
-#define ARM64_NCAPS 43
+#define ARM64_NCAPS 44
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5e27d2dbe45e..c74b25895c43 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.field_pos = ID_AA64ISAR1_DPB_SHIFT,
.min_field_value = 1,
},
+ {
+ .desc = "Data cache clean to Point of Deep Persistence",
+ .capability = ARM64_HAS_DCPODP,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_cpuid_feature,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .field_pos = ID_AA64ISAR1_DPB_SHIFT,
+ .min_field_value = 2,
+ },
#endif
#ifdef CONFIG_ARM64_SVE
{
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 9 +++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index f6a76e43f39e..defdc67d9ab4 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -61,7 +61,8 @@
#define ARM64_HAS_GENERIC_AUTH_ARCH 40
#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
#define ARM64_HAS_IRQ_PRIO_MASKING 42
+#define ARM64_HAS_DCPODP 43
-#define ARM64_NCAPS 43
+#define ARM64_NCAPS 44
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5e27d2dbe45e..c74b25895c43 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.field_pos = ID_AA64ISAR1_DPB_SHIFT,
.min_field_value = 1,
},
+ {
+ .desc = "Data cache clean to Point of Deep Persistence",
+ .capability = ARM64_HAS_DCPODP,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_cpuid_feature,
+ .sys_reg = SYS_ID_AA64ISAR1_EL1,
+ .field_pos = ID_AA64ISAR1_DPB_SHIFT,
+ .min_field_value = 2,
+ },
#endif
#ifdef CONFIG_ARM64_SVE
{
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 7/7] arm64: docs: document AT_HWCAP2 and unused AT_HWCAP bits
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-01 10:45 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Szabolcs Nagy, dave.martin, linux-arm-kernel, Mark Rutland,
Phil Blundell, libc-alpha, linux-api
Now that we have expanded into AT_HWCAP2 let's add some documentation
to describe its presence. We also document the unused top half of
AT_HWCAP which we always return as 0 for userspace interoperation.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
Documentation/arm64/elf_hwcaps.txt | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index c605757dd4db..6b3d4d334db7 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -13,9 +13,9 @@ architected discovery mechanism available to userspace code at EL0. The
kernel exposes the presence of these features to userspace through a set
of flags called hwcaps, exposed in the auxilliary vector.
-Userspace software can test for features by acquiring the AT_HWCAP entry
-of the auxilliary vector, and testing whether the relevant flags are
-set, e.g.
+Userspace software can test for features by acquiring the AT_HWCAP or
+AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+flags are set, e.g.
bool floating_point_is_present(void)
{
@@ -198,3 +198,11 @@ HWCAP_PACG
Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
Documentation/arm64/pointer-authentication.txt.
+
+
+4. Unused AT_HWCAP bits
+-----------------------
+
+Each AT_HWCAP and AT_HWCAP2 entry provides for up to 32 hwcaps contained
+in bits [31:0]. For interoperation with userspace we guarantee that bit
+62 of AT_HWCAP will always be returned as 0.
--
2.21.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 7/7] arm64: docs: document AT_HWCAP2 and unused AT_HWCAP bits
@ 2019-04-01 10:45 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-01 10:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, linux-api,
Phil Blundell, dave.martin, linux-arm-kernel
Now that we have expanded into AT_HWCAP2 let's add some documentation
to describe its presence. We also document the unused top half of
AT_HWCAP which we always return as 0 for userspace interoperation.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
Documentation/arm64/elf_hwcaps.txt | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index c605757dd4db..6b3d4d334db7 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -13,9 +13,9 @@ architected discovery mechanism available to userspace code at EL0. The
kernel exposes the presence of these features to userspace through a set
of flags called hwcaps, exposed in the auxilliary vector.
-Userspace software can test for features by acquiring the AT_HWCAP entry
-of the auxilliary vector, and testing whether the relevant flags are
-set, e.g.
+Userspace software can test for features by acquiring the AT_HWCAP or
+AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+flags are set, e.g.
bool floating_point_is_present(void)
{
@@ -198,3 +198,11 @@ HWCAP_PACG
Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
Documentation/arm64/pointer-authentication.txt.
+
+
+4. Unused AT_HWCAP bits
+-----------------------
+
+Each AT_HWCAP and AT_HWCAP2 entry provides for up to 32 hwcaps contained
+in bits [31:0]. For interoperation with userspace we guarantee that bit
+62 of AT_HWCAP will always be returned as 0.
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-02 14:58 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:58 UTC (permalink / raw)
To: Andrew Murray
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> The introduction of AT_HWCAP2 introduced accessors which ensure that
> hwcap features are set and tested appropriately.
>
> Let's now mandate access to elf_hwcap via these accessors by making
> elf_hwcap static within cpufeature.c.
Looks reasonable except for a couple of minor nits below.
I had wondered whether putting these accessors out of line would affect
any hot paths, but I can't see these used from anything that looks like
a hot path. So we're probably fine.
cpus_have_const_cap() is preferred for places where this matters,
anyway.
[...]
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 986ceeacd19f..84ca52fa75e5 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -35,8 +35,7 @@
> #include <asm/traps.h>
> #include <asm/virt.h>
>
> -unsigned long elf_hwcap __read_mostly;
> -EXPORT_SYMBOL_GPL(elf_hwcap);
> +static unsigned long elf_hwcap __read_mostly;
Now that this doesn't correspond directly to ELF_HWCAP any more and we
hide it, can we rename it to avoid confusion?
Maybe "kernel_hwcap"?
> #ifdef CONFIG_COMPAT
> #define COMPAT_ELF_HWCAP_DEFAULT \
> @@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
> return false;
> }
>
> +void cpu_set_feature(unsigned int num)
> +{
> + WARN_ON(num >= MAX_CPU_FEATURES);
> + elf_hwcap |= BIT(num);
> +}
> +EXPORT_SYMBOL_GPL(cpu_set_feature);
> +
> +bool cpu_have_feature(unsigned int num)
> +{
> + WARN_ON(num >= MAX_CPU_FEATURES);
> + return elf_hwcap & BIT(num);
> +}
> +EXPORT_SYMBOL_GPL(cpu_have_feature);
> +
> +unsigned long cpu_get_elf_hwcap(void)
> +{
> + /*
> + * We currently only populate the first 32 bits of AT_HWCAP. Please
> + * note that for userspace compatibility we guarantee that bit 62
> + * will always be returned as 0.
> + */
Presumably also bit 63?
It is reasonable to say this here, but I think there should also be a
note in Documentation/arm64/elf_hwcaps.txt.
[...]
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-02 14:58 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:58 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> The introduction of AT_HWCAP2 introduced accessors which ensure that
> hwcap features are set and tested appropriately.
>
> Let's now mandate access to elf_hwcap via these accessors by making
> elf_hwcap static within cpufeature.c.
Looks reasonable except for a couple of minor nits below.
I had wondered whether putting these accessors out of line would affect
any hot paths, but I can't see these used from anything that looks like
a hot path. So we're probably fine.
cpus_have_const_cap() is preferred for places where this matters,
anyway.
[...]
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 986ceeacd19f..84ca52fa75e5 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -35,8 +35,7 @@
> #include <asm/traps.h>
> #include <asm/virt.h>
>
> -unsigned long elf_hwcap __read_mostly;
> -EXPORT_SYMBOL_GPL(elf_hwcap);
> +static unsigned long elf_hwcap __read_mostly;
Now that this doesn't correspond directly to ELF_HWCAP any more and we
hide it, can we rename it to avoid confusion?
Maybe "kernel_hwcap"?
> #ifdef CONFIG_COMPAT
> #define COMPAT_ELF_HWCAP_DEFAULT \
> @@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
> return false;
> }
>
> +void cpu_set_feature(unsigned int num)
> +{
> + WARN_ON(num >= MAX_CPU_FEATURES);
> + elf_hwcap |= BIT(num);
> +}
> +EXPORT_SYMBOL_GPL(cpu_set_feature);
> +
> +bool cpu_have_feature(unsigned int num)
> +{
> + WARN_ON(num >= MAX_CPU_FEATURES);
> + return elf_hwcap & BIT(num);
> +}
> +EXPORT_SYMBOL_GPL(cpu_have_feature);
> +
> +unsigned long cpu_get_elf_hwcap(void)
> +{
> + /*
> + * We currently only populate the first 32 bits of AT_HWCAP. Please
> + * note that for userspace compatibility we guarantee that bit 62
> + * will always be returned as 0.
> + */
Presumably also bit 63?
It is reasonable to say this here, but I think there should also be a
note in Documentation/arm64/elf_hwcaps.txt.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-02 14:58 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:58 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
> As we will exhaust the first 32 bits of AT_HWCAP let's start
> exposing AT_HWCAP2 to userspace to give us up to 64 caps.
>
> Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
> prefer to expand into AT_HWCAP2 in order to provide a consistent
> view to userspace between ILP32 and LP64. However internal to the
> kernel we prefer to continue to use the full space of elf_hwcap.
>
> To reduce complexity and allow for future expansion, we now
> represent hwcaps in the kernel as ordinals and use a
> KERNEL_HWCAP_ prefix. This allows us to support automatic feature
> based module loading for all our hwcaps.
>
> We introduce cpu_set_feature to set hwcaps which compliments the
Nit: maybe "complements"? (I've always been a bit fuzzy on the precise
distinction, though.)
> existing cpu_have_feature helper. These helpers allow us to clean
> up existing direct uses of elf_hwcap and reduce any future effort
> required to move beyond 64 caps.
>
> For convenience we also introduce cpu_{have,set}_named_feature which
> makes use of the cpu_feature macro to allow providing a hwcap name
> without a {KERNEL_}HWCAP_ prefix.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
> arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
> arch/arm64/crypto/chacha-neon-glue.c | 2 +-
> arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
> arch/arm64/crypto/ghash-ce-glue.c | 8 +--
> arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
> arch/arm64/crypto/sha256-glue.c | 4 +-
> arch/arm64/include/asm/cpufeature.h | 22 ++++----
> arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
> arch/arm64/include/uapi/asm/hwcap.h | 2 +-
> arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
> arch/arm64/kernel/cpuinfo.c | 2 +-
> arch/arm64/kernel/fpsimd.c | 4 +-
> drivers/clocksource/arm_arch_timer.c | 8 +++
> 14 files changed, 117 insertions(+), 60 deletions(-)
>
[...]
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index e505e1fbd2b9..f06e1da1d678 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -14,15 +14,8 @@
> #include <asm/hwcap.h>
> #include <asm/sysreg.h>
>
> -/*
> - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
> - * in the kernel and for user space to keep track of which optional features
> - * are supported by the current system. So let's map feature 'x' to HWCAP_x.
> - * Note that HWCAP_x constants are bit fields so we need to take the log.
> - */
> -
> -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
> -#define cpu_feature(x) ilog2(HWCAP_ ## x)
> +#define MAX_CPU_FEATURES 64
> +#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
Nit: do we need the () here? They may be defensive, but I'm not sure
they're required.
[...]
> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> index 400b80b49595..d21fe3314d90 100644
> --- a/arch/arm64/include/asm/hwcap.h
> +++ b/arch/arm64/include/asm/hwcap.h
> @@ -39,12 +39,59 @@
> #define COMPAT_HWCAP2_SHA2 (1 << 3)
> #define COMPAT_HWCAP2_CRC32 (1 << 4)
>
> +/*
> + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
> + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
> + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
> + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
> + *
> + * Hwcaps should be set and tested within the kernel via the
> + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
> + * of KERNEL_HWCAP_{feature}.
> + */
> +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
> +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
> +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
> +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
> +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
> +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
> +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
> +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
> +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
> +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
> +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
> +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
> +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
> +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
> +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
> +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
> +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
> +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
> +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
> +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
> +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
> +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
> +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
> +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
> +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
> +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
> +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
> +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
> +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
> +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
> +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
> +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
> +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out
each time?
If we are splitting ths CVADP support from this patch, then dropping
such a wrapper macro here (maybe with a comment) will serve as a
placeholder for whichever patch wins the race for the first HWCAP2
flag.
Say
#define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32)
(Optionally, we could also have __khwcap_feature() too so that
everything looks nice and regular.)
[...]
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index aa4ec53281ce..6cc8aff83805 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> | ARCH_TIMER_VIRT_EVT_EN;
> arch_timer_set_cntkctl(cntkctl);
> +#ifdef CONFIG_ARM64
> + cpu_set_named_feature(EVTSTRM);
> +#else
> elf_hwcap |= HWCAP_EVTSTRM;
> +#endif
I wonder whether we can have a generic definition for this:
#define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
seems a reasonable fallback when the arch doesn't provide its own
version.
Although we don't have many instances, it would still be nice to avoid
ifdeffery creeping in.
[...]
We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into
this patch.
It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt
updates alongside this patch in the series (or even incorporate them
into this patch, since they're not huge.)
Other than that, looks reasonable to me.
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-02 14:58 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:58 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
> As we will exhaust the first 32 bits of AT_HWCAP let's start
> exposing AT_HWCAP2 to userspace to give us up to 64 caps.
>
> Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
> prefer to expand into AT_HWCAP2 in order to provide a consistent
> view to userspace between ILP32 and LP64. However internal to the
> kernel we prefer to continue to use the full space of elf_hwcap.
>
> To reduce complexity and allow for future expansion, we now
> represent hwcaps in the kernel as ordinals and use a
> KERNEL_HWCAP_ prefix. This allows us to support automatic feature
> based module loading for all our hwcaps.
>
> We introduce cpu_set_feature to set hwcaps which compliments the
Nit: maybe "complements"? (I've always been a bit fuzzy on the precise
distinction, though.)
> existing cpu_have_feature helper. These helpers allow us to clean
> up existing direct uses of elf_hwcap and reduce any future effort
> required to move beyond 64 caps.
>
> For convenience we also introduce cpu_{have,set}_named_feature which
> makes use of the cpu_feature macro to allow providing a hwcap name
> without a {KERNEL_}HWCAP_ prefix.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
> arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
> arch/arm64/crypto/chacha-neon-glue.c | 2 +-
> arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
> arch/arm64/crypto/ghash-ce-glue.c | 8 +--
> arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
> arch/arm64/crypto/sha256-glue.c | 4 +-
> arch/arm64/include/asm/cpufeature.h | 22 ++++----
> arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
> arch/arm64/include/uapi/asm/hwcap.h | 2 +-
> arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
> arch/arm64/kernel/cpuinfo.c | 2 +-
> arch/arm64/kernel/fpsimd.c | 4 +-
> drivers/clocksource/arm_arch_timer.c | 8 +++
> 14 files changed, 117 insertions(+), 60 deletions(-)
>
[...]
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index e505e1fbd2b9..f06e1da1d678 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -14,15 +14,8 @@
> #include <asm/hwcap.h>
> #include <asm/sysreg.h>
>
> -/*
> - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
> - * in the kernel and for user space to keep track of which optional features
> - * are supported by the current system. So let's map feature 'x' to HWCAP_x.
> - * Note that HWCAP_x constants are bit fields so we need to take the log.
> - */
> -
> -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
> -#define cpu_feature(x) ilog2(HWCAP_ ## x)
> +#define MAX_CPU_FEATURES 64
> +#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
Nit: do we need the () here? They may be defensive, but I'm not sure
they're required.
[...]
> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> index 400b80b49595..d21fe3314d90 100644
> --- a/arch/arm64/include/asm/hwcap.h
> +++ b/arch/arm64/include/asm/hwcap.h
> @@ -39,12 +39,59 @@
> #define COMPAT_HWCAP2_SHA2 (1 << 3)
> #define COMPAT_HWCAP2_CRC32 (1 << 4)
>
> +/*
> + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
> + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
> + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
> + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
> + *
> + * Hwcaps should be set and tested within the kernel via the
> + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
> + * of KERNEL_HWCAP_{feature}.
> + */
> +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
> +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
> +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
> +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
> +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
> +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
> +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
> +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
> +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
> +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
> +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
> +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
> +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
> +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
> +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
> +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
> +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
> +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
> +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
> +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
> +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
> +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
> +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
> +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
> +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
> +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
> +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
> +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
> +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
> +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
> +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
> +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
> +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out
each time?
If we are splitting ths CVADP support from this patch, then dropping
such a wrapper macro here (maybe with a comment) will serve as a
placeholder for whichever patch wins the race for the first HWCAP2
flag.
Say
#define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32)
(Optionally, we could also have __khwcap_feature() too so that
everything looks nice and regular.)
[...]
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index aa4ec53281ce..6cc8aff83805 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> | ARCH_TIMER_VIRT_EVT_EN;
> arch_timer_set_cntkctl(cntkctl);
> +#ifdef CONFIG_ARM64
> + cpu_set_named_feature(EVTSTRM);
> +#else
> elf_hwcap |= HWCAP_EVTSTRM;
> +#endif
I wonder whether we can have a generic definition for this:
#define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
seems a reasonable fallback when the arch doesn't provide its own
version.
Although we don't have many instances, it would still be nice to avoid
ifdeffery creeping in.
[...]
We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into
this patch.
It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt
updates alongside this patch in the series (or even incorporate them
into this patch, since they're not huge.)
Other than that, looks reasonable to me.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
2019-04-01 10:45 ` Andrew Murray
@ 2019-04-02 14:59 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:59 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
Do you mean ARM64_HAS_DCPODP?
And do we need this? This capability flag doesn't currently appear to
be used for anything (which makes me wonder whether it _should_ be wired
up to something in the kernel).
Do we expect the kernel to do something special with this in the future?
OTOH, we get a nice printk when the feature is detected, and the code
size cost is insignificant. So, if there's a reasonable expectation that
we will use it someday, I don't see a big problem with having it.
Cheers
---Dave
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/kernel/cpufeature.c | 9 +++++++++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index f6a76e43f39e..defdc67d9ab4 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -61,7 +61,8 @@
> #define ARM64_HAS_GENERIC_AUTH_ARCH 40
> #define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
> #define ARM64_HAS_IRQ_PRIO_MASKING 42
> +#define ARM64_HAS_DCPODP 43
>
> -#define ARM64_NCAPS 43
> +#define ARM64_NCAPS 44
>
> #endif /* __ASM_CPUCAPS_H */
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 5e27d2dbe45e..c74b25895c43 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> .min_field_value = 1,
> },
> + {
> + .desc = "Data cache clean to Point of Deep Persistence",
> + .capability = ARM64_HAS_DCPODP,
> + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> + .matches = has_cpuid_feature,
> + .sys_reg = SYS_ID_AA64ISAR1_EL1,
> + .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> + .min_field_value = 2,
> + },
> #endif
> #ifdef CONFIG_ARM64_SVE
> {
> --
> 2.21.0
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
@ 2019-04-02 14:59 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 14:59 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
Do you mean ARM64_HAS_DCPODP?
And do we need this? This capability flag doesn't currently appear to
be used for anything (which makes me wonder whether it _should_ be wired
up to something in the kernel).
Do we expect the kernel to do something special with this in the future?
OTOH, we get a nice printk when the feature is detected, and the code
size cost is insignificant. So, if there's a reasonable expectation that
we will use it someday, I don't see a big problem with having it.
Cheers
---Dave
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/kernel/cpufeature.c | 9 +++++++++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index f6a76e43f39e..defdc67d9ab4 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -61,7 +61,8 @@
> #define ARM64_HAS_GENERIC_AUTH_ARCH 40
> #define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
> #define ARM64_HAS_IRQ_PRIO_MASKING 42
> +#define ARM64_HAS_DCPODP 43
>
> -#define ARM64_NCAPS 43
> +#define ARM64_NCAPS 44
>
> #endif /* __ASM_CPUCAPS_H */
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 5e27d2dbe45e..c74b25895c43 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> .min_field_value = 1,
> },
> + {
> + .desc = "Data cache clean to Point of Deep Persistence",
> + .capability = ARM64_HAS_DCPODP,
> + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> + .matches = has_cpuid_feature,
> + .sys_reg = SYS_ID_AA64ISAR1_EL1,
> + .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> + .min_field_value = 2,
> + },
> #endif
> #ifdef CONFIG_ARM64_SVE
> {
> --
> 2.21.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-02 14:58 ` Dave Martin
@ 2019-04-02 15:06 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-02 15:06 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> > The introduction of AT_HWCAP2 introduced accessors which ensure that
> > hwcap features are set and tested appropriately.
> >
> > Let's now mandate access to elf_hwcap via these accessors by making
> > elf_hwcap static within cpufeature.c.
>
> Looks reasonable except for a couple of minor nits below.
>
> I had wondered whether putting these accessors out of line would affect
> any hot paths, but I can't see these used from anything that looks like
> a hot path. So we're probably fine.
>
> cpus_have_const_cap() is preferred for places where this matters,
> anyway.
>
> [...]
>
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 986ceeacd19f..84ca52fa75e5 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -35,8 +35,7 @@
> > #include <asm/traps.h>
> > #include <asm/virt.h>
> >
> > -unsigned long elf_hwcap __read_mostly;
> > -EXPORT_SYMBOL_GPL(elf_hwcap);
> > +static unsigned long elf_hwcap __read_mostly;
>
> Now that this doesn't correspond directly to ELF_HWCAP any more and we
> hide it, can we rename it to avoid confusion?
>
> Maybe "kernel_hwcap"?
Yes this seems reasonable.
>
> > #ifdef CONFIG_COMPAT
> > #define COMPAT_ELF_HWCAP_DEFAULT \
> > @@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
> > return false;
> > }
> >
> > +void cpu_set_feature(unsigned int num)
> > +{
> > + WARN_ON(num >= MAX_CPU_FEATURES);
> > + elf_hwcap |= BIT(num);
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_set_feature);
> > +
> > +bool cpu_have_feature(unsigned int num)
> > +{
> > + WARN_ON(num >= MAX_CPU_FEATURES);
> > + return elf_hwcap & BIT(num);
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_have_feature);
> > +
> > +unsigned long cpu_get_elf_hwcap(void)
> > +{
> > + /*
> > + * We currently only populate the first 32 bits of AT_HWCAP. Please
> > + * note that for userspace compatibility we guarantee that bit 62
> > + * will always be returned as 0.
> > + */
>
> Presumably also bit 63?
Yes, I will add this too.
>
> It is reasonable to say this here, but I think there should also be a
> note in Documentation/arm64/elf_hwcaps.txt.
This is already present in this series, I'll update it to reflect bit 63
also.
Thanks,
Andrew Murray
>
> [...]
>
> Cheers
> ---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-02 15:06 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-02 15:06 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> > The introduction of AT_HWCAP2 introduced accessors which ensure that
> > hwcap features are set and tested appropriately.
> >
> > Let's now mandate access to elf_hwcap via these accessors by making
> > elf_hwcap static within cpufeature.c.
>
> Looks reasonable except for a couple of minor nits below.
>
> I had wondered whether putting these accessors out of line would affect
> any hot paths, but I can't see these used from anything that looks like
> a hot path. So we're probably fine.
>
> cpus_have_const_cap() is preferred for places where this matters,
> anyway.
>
> [...]
>
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 986ceeacd19f..84ca52fa75e5 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -35,8 +35,7 @@
> > #include <asm/traps.h>
> > #include <asm/virt.h>
> >
> > -unsigned long elf_hwcap __read_mostly;
> > -EXPORT_SYMBOL_GPL(elf_hwcap);
> > +static unsigned long elf_hwcap __read_mostly;
>
> Now that this doesn't correspond directly to ELF_HWCAP any more and we
> hide it, can we rename it to avoid confusion?
>
> Maybe "kernel_hwcap"?
Yes this seems reasonable.
>
> > #ifdef CONFIG_COMPAT
> > #define COMPAT_ELF_HWCAP_DEFAULT \
> > @@ -1947,6 +1946,35 @@ bool this_cpu_has_cap(unsigned int n)
> > return false;
> > }
> >
> > +void cpu_set_feature(unsigned int num)
> > +{
> > + WARN_ON(num >= MAX_CPU_FEATURES);
> > + elf_hwcap |= BIT(num);
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_set_feature);
> > +
> > +bool cpu_have_feature(unsigned int num)
> > +{
> > + WARN_ON(num >= MAX_CPU_FEATURES);
> > + return elf_hwcap & BIT(num);
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_have_feature);
> > +
> > +unsigned long cpu_get_elf_hwcap(void)
> > +{
> > + /*
> > + * We currently only populate the first 32 bits of AT_HWCAP. Please
> > + * note that for userspace compatibility we guarantee that bit 62
> > + * will always be returned as 0.
> > + */
>
> Presumably also bit 63?
Yes, I will add this too.
>
> It is reasonable to say this here, but I think there should also be a
> note in Documentation/arm64/elf_hwcaps.txt.
This is already present in this series, I'll update it to reflect bit 63
also.
Thanks,
Andrew Murray
>
> [...]
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-02 15:06 ` Andrew Murray
@ 2019-04-02 15:32 ` Suzuki K Poulose
-1 siblings, 0 replies; 46+ messages in thread
From: Suzuki K Poulose @ 2019-04-02 15:32 UTC (permalink / raw)
To: andrew.murray, dave.martin
Cc: mark.rutland, libc-alpha, Szabolcs.Nagy, catalin.marinas,
will.deacon, pb, linux-api, linux-arm-kernel
Hi,
On 02/04/2019 16:06, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
>> On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
>>> The introduction of AT_HWCAP2 introduced accessors which ensure that
>>> hwcap features are set and tested appropriately.
>>>
>>> Let's now mandate access to elf_hwcap via these accessors by making
>>> elf_hwcap static within cpufeature.c.
>>
>> Looks reasonable except for a couple of minor nits below.
>>
>> I had wondered whether putting these accessors out of line would affect
>> any hot paths, but I can't see these used from anything that looks like
>> a hot path. So we're probably fine.
>>
>> cpus_have_const_cap() is preferred for places where this matters,
>> anyway.
Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
>>
>> [...]
>>
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 986ceeacd19f..84ca52fa75e5 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -35,8 +35,7 @@
>>> #include <asm/traps.h>
>>> #include <asm/virt.h>
>>>
>>> -unsigned long elf_hwcap __read_mostly;
>>> -EXPORT_SYMBOL_GPL(elf_hwcap);
>>> +static unsigned long elf_hwcap __read_mostly;
>>
>> Now that this doesn't correspond directly to ELF_HWCAP any more and we
>> hide it, can we rename it to avoid confusion?
>>
>> Maybe "kernel_hwcap"?
>
> Yes this seems reasonable.
nit:
As mentioned above we have "cpu_hwcaps" for the features only internally
by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
major purpose is for userspace consumption and could easily confuse with
the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
How about "user_hwcaps" ? Or preferrably something closer to that.
Cheers
Suzuki
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-02 15:32 ` Suzuki K Poulose
0 siblings, 0 replies; 46+ messages in thread
From: Suzuki K Poulose @ 2019-04-02 15:32 UTC (permalink / raw)
To: andrew.murray, dave.martin
Cc: mark.rutland, libc-alpha, Szabolcs.Nagy, catalin.marinas,
will.deacon, pb, linux-api, linux-arm-kernel
Hi,
On 02/04/2019 16:06, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
>> On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
>>> The introduction of AT_HWCAP2 introduced accessors which ensure that
>>> hwcap features are set and tested appropriately.
>>>
>>> Let's now mandate access to elf_hwcap via these accessors by making
>>> elf_hwcap static within cpufeature.c.
>>
>> Looks reasonable except for a couple of minor nits below.
>>
>> I had wondered whether putting these accessors out of line would affect
>> any hot paths, but I can't see these used from anything that looks like
>> a hot path. So we're probably fine.
>>
>> cpus_have_const_cap() is preferred for places where this matters,
>> anyway.
Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
>>
>> [...]
>>
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 986ceeacd19f..84ca52fa75e5 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -35,8 +35,7 @@
>>> #include <asm/traps.h>
>>> #include <asm/virt.h>
>>>
>>> -unsigned long elf_hwcap __read_mostly;
>>> -EXPORT_SYMBOL_GPL(elf_hwcap);
>>> +static unsigned long elf_hwcap __read_mostly;
>>
>> Now that this doesn't correspond directly to ELF_HWCAP any more and we
>> hide it, can we rename it to avoid confusion?
>>
>> Maybe "kernel_hwcap"?
>
> Yes this seems reasonable.
nit:
As mentioned above we have "cpu_hwcaps" for the features only internally
by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
major purpose is for userspace consumption and could easily confuse with
the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
How about "user_hwcaps" ? Or preferrably something closer to that.
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-02 15:32 ` Suzuki K Poulose
@ 2019-04-02 15:55 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 15:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: andrew.murray, mark.rutland, libc-alpha, Szabolcs.Nagy,
catalin.marinas, will.deacon, pb, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
> Hi,
>
> On 02/04/2019 16:06, Andrew Murray wrote:
> >On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> >>On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> >>>The introduction of AT_HWCAP2 introduced accessors which ensure that
> >>>hwcap features are set and tested appropriately.
> >>>
> >>>Let's now mandate access to elf_hwcap via these accessors by making
> >>>elf_hwcap static within cpufeature.c.
> >>
> >>Looks reasonable except for a couple of minor nits below.
> >>
> >>I had wondered whether putting these accessors out of line would affect
> >>any hot paths, but I can't see these used from anything that looks like
> >>a hot path. So we're probably fine.
> >>
> >>cpus_have_const_cap() is preferred for places where this matters,
> >>anyway.
>
> Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
Sure, I meant: where we need to test something fast, we can have a
cpucap for it, rather than rely on the ELF hwcaps.
In practice, we already follow this pattern today: ELF hwcap flags are
tested in a few places, but I don't see anything that is fast-path.
>
> >>
> >>[...]
> >>
> >>>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>>index 986ceeacd19f..84ca52fa75e5 100644
> >>>--- a/arch/arm64/kernel/cpufeature.c
> >>>+++ b/arch/arm64/kernel/cpufeature.c
> >>>@@ -35,8 +35,7 @@
> >>> #include <asm/traps.h>
> >>> #include <asm/virt.h>
> >>>-unsigned long elf_hwcap __read_mostly;
> >>>-EXPORT_SYMBOL_GPL(elf_hwcap);
> >>>+static unsigned long elf_hwcap __read_mostly;
> >>
> >>Now that this doesn't correspond directly to ELF_HWCAP any more and we
> >>hide it, can we rename it to avoid confusion?
> >>
> >>Maybe "kernel_hwcap"?
> >
> >Yes this seems reasonable.
>
> nit:
>
> As mentioned above we have "cpu_hwcaps" for the features only internally
> by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> major purpose is for userspace consumption and could easily confuse with
> the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
>
> How about "user_hwcaps" ? Or preferrably something closer to that.
Yes, that may be better.
Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
Since kernel_hwcap is just a static variable now, maybe it's sufficient
to stick a comment next to it explaining what it is (and what it isn't).
"user_hwcaps" still implies that this might be the userspace view of the
flags, which it isn't.
But I don't feel strongly about this. If someone wants to make a
decision, I'm happy to defer to it.
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-02 15:55 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-02 15:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: mark.rutland, libc-alpha, Szabolcs.Nagy, catalin.marinas,
will.deacon, pb, linux-api, andrew.murray, linux-arm-kernel
On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
> Hi,
>
> On 02/04/2019 16:06, Andrew Murray wrote:
> >On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> >>On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> >>>The introduction of AT_HWCAP2 introduced accessors which ensure that
> >>>hwcap features are set and tested appropriately.
> >>>
> >>>Let's now mandate access to elf_hwcap via these accessors by making
> >>>elf_hwcap static within cpufeature.c.
> >>
> >>Looks reasonable except for a couple of minor nits below.
> >>
> >>I had wondered whether putting these accessors out of line would affect
> >>any hot paths, but I can't see these used from anything that looks like
> >>a hot path. So we're probably fine.
> >>
> >>cpus_have_const_cap() is preferred for places where this matters,
> >>anyway.
>
> Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
Sure, I meant: where we need to test something fast, we can have a
cpucap for it, rather than rely on the ELF hwcaps.
In practice, we already follow this pattern today: ELF hwcap flags are
tested in a few places, but I don't see anything that is fast-path.
>
> >>
> >>[...]
> >>
> >>>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>>index 986ceeacd19f..84ca52fa75e5 100644
> >>>--- a/arch/arm64/kernel/cpufeature.c
> >>>+++ b/arch/arm64/kernel/cpufeature.c
> >>>@@ -35,8 +35,7 @@
> >>> #include <asm/traps.h>
> >>> #include <asm/virt.h>
> >>>-unsigned long elf_hwcap __read_mostly;
> >>>-EXPORT_SYMBOL_GPL(elf_hwcap);
> >>>+static unsigned long elf_hwcap __read_mostly;
> >>
> >>Now that this doesn't correspond directly to ELF_HWCAP any more and we
> >>hide it, can we rename it to avoid confusion?
> >>
> >>Maybe "kernel_hwcap"?
> >
> >Yes this seems reasonable.
>
> nit:
>
> As mentioned above we have "cpu_hwcaps" for the features only internally
> by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> major purpose is for userspace consumption and could easily confuse with
> the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
>
> How about "user_hwcaps" ? Or preferrably something closer to that.
Yes, that may be better.
Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
Since kernel_hwcap is just a static variable now, maybe it's sufficient
to stick a comment next to it explaining what it is (and what it isn't).
"user_hwcaps" still implies that this might be the userspace view of the
flags, which it isn't.
But I don't feel strongly about this. If someone wants to make a
decision, I'm happy to defer to it.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-02 14:58 ` Dave Martin
@ 2019-04-03 8:32 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 8:32 UTC (permalink / raw)
To: Dave Martin
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
> > As we will exhaust the first 32 bits of AT_HWCAP let's start
> > exposing AT_HWCAP2 to userspace to give us up to 64 caps.
> >
> > Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
> > prefer to expand into AT_HWCAP2 in order to provide a consistent
> > view to userspace between ILP32 and LP64. However internal to the
> > kernel we prefer to continue to use the full space of elf_hwcap.
> >
> > To reduce complexity and allow for future expansion, we now
> > represent hwcaps in the kernel as ordinals and use a
> > KERNEL_HWCAP_ prefix. This allows us to support automatic feature
> > based module loading for all our hwcaps.
> >
> > We introduce cpu_set_feature to set hwcaps which compliments the
>
> Nit: maybe "complements"? (I've always been a bit fuzzy on the precise
> distinction, though.)
Yes this is the correct spelling (as I'm pretty sure the cpu_have_feature
helper doesn't have a tips jar).
>
> > existing cpu_have_feature helper. These helpers allow us to clean
> > up existing direct uses of elf_hwcap and reduce any future effort
> > required to move beyond 64 caps.
> >
> > For convenience we also introduce cpu_{have,set}_named_feature which
> > makes use of the cpu_feature macro to allow providing a hwcap name
> > without a {KERNEL_}HWCAP_ prefix.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
> > arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
> > arch/arm64/crypto/chacha-neon-glue.c | 2 +-
> > arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
> > arch/arm64/crypto/ghash-ce-glue.c | 8 +--
> > arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
> > arch/arm64/crypto/sha256-glue.c | 4 +-
> > arch/arm64/include/asm/cpufeature.h | 22 ++++----
> > arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
> > arch/arm64/include/uapi/asm/hwcap.h | 2 +-
> > arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
> > arch/arm64/kernel/cpuinfo.c | 2 +-
> > arch/arm64/kernel/fpsimd.c | 4 +-
> > drivers/clocksource/arm_arch_timer.c | 8 +++
> > 14 files changed, 117 insertions(+), 60 deletions(-)
> >
>
> [...]
>
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index e505e1fbd2b9..f06e1da1d678 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -14,15 +14,8 @@
> > #include <asm/hwcap.h>
> > #include <asm/sysreg.h>
> >
> > -/*
> > - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
> > - * in the kernel and for user space to keep track of which optional features
> > - * are supported by the current system. So let's map feature 'x' to HWCAP_x.
> > - * Note that HWCAP_x constants are bit fields so we need to take the log.
> > - */
> > -
> > -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
> > -#define cpu_feature(x) ilog2(HWCAP_ ## x)
> > +#define MAX_CPU_FEATURES 64
> > +#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
>
> Nit: do we need the () here? They may be defensive, but I'm not sure
> they're required.
I guess not, checkpatch doesn't complain - I'll remove them.
>
> [...]
>
> > diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> > index 400b80b49595..d21fe3314d90 100644
> > --- a/arch/arm64/include/asm/hwcap.h
> > +++ b/arch/arm64/include/asm/hwcap.h
> > @@ -39,12 +39,59 @@
> > #define COMPAT_HWCAP2_SHA2 (1 << 3)
> > #define COMPAT_HWCAP2_CRC32 (1 << 4)
> >
> > +/*
> > + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
> > + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
> > + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
> > + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
> > + *
> > + * Hwcaps should be set and tested within the kernel via the
> > + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
> > + * of KERNEL_HWCAP_{feature}.
> > + */
> > +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
> > +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
> > +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
> > +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
> > +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
> > +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
> > +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
> > +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
> > +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
> > +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
> > +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
> > +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
> > +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
> > +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
> > +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
> > +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
> > +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
> > +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
> > +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
> > +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
> > +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
> > +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
> > +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
> > +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
> > +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
> > +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
> > +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
> > +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
> > +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
> > +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
> > +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
> > +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
> > +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
>
> Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out
> each time?
>
> If we are splitting ths CVADP support from this patch, then dropping
> such a wrapper macro here (maybe with a comment) will serve as a
> placeholder for whichever patch wins the race for the first HWCAP2
> flag.
>
> Say
>
> #define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32)
>
> (Optionally, we could also have __khwcap_feature() too so that
> everything looks nice and regular.)
Yes this makes sense, thanks for the suggestion.
>
> [...]
>
> > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > index aa4ec53281ce..6cc8aff83805 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > | ARCH_TIMER_VIRT_EVT_EN;
> > arch_timer_set_cntkctl(cntkctl);
> > +#ifdef CONFIG_ARM64
> > + cpu_set_named_feature(EVTSTRM);
> > +#else
> > elf_hwcap |= HWCAP_EVTSTRM;
> > +#endif
>
> I wonder whether we can have a generic definition for this:
>
> #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
You mean specific to arm32?
I will do this, along with a cpu_get_named_feature - but I think I'd prefer
to do this in a separate series.
>
> seems a reasonable fallback when the arch doesn't provide its own
> version.
>
>
> Although we don't have many instances, it would still be nice to avoid
> ifdeffery creeping in.
>
> [...]
>
> We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into
> this patch.
>
> It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt
> updates alongside this patch in the series (or even incorporate them
> into this patch, since they're not huge.)
Yes that's OK.
>
> Other than that, looks reasonable to me.
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-03 8:32 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 8:32 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
> > As we will exhaust the first 32 bits of AT_HWCAP let's start
> > exposing AT_HWCAP2 to userspace to give us up to 64 caps.
> >
> > Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we
> > prefer to expand into AT_HWCAP2 in order to provide a consistent
> > view to userspace between ILP32 and LP64. However internal to the
> > kernel we prefer to continue to use the full space of elf_hwcap.
> >
> > To reduce complexity and allow for future expansion, we now
> > represent hwcaps in the kernel as ordinals and use a
> > KERNEL_HWCAP_ prefix. This allows us to support automatic feature
> > based module loading for all our hwcaps.
> >
> > We introduce cpu_set_feature to set hwcaps which compliments the
>
> Nit: maybe "complements"? (I've always been a bit fuzzy on the precise
> distinction, though.)
Yes this is the correct spelling (as I'm pretty sure the cpu_have_feature
helper doesn't have a tips jar).
>
> > existing cpu_have_feature helper. These helpers allow us to clean
> > up existing direct uses of elf_hwcap and reduce any future effort
> > required to move beyond 64 caps.
> >
> > For convenience we also introduce cpu_{have,set}_named_feature which
> > makes use of the cpu_feature macro to allow providing a hwcap name
> > without a {KERNEL_}HWCAP_ prefix.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +-
> > arch/arm64/crypto/aes-neonbs-glue.c | 2 +-
> > arch/arm64/crypto/chacha-neon-glue.c | 2 +-
> > arch/arm64/crypto/crct10dif-ce-glue.c | 4 +-
> > arch/arm64/crypto/ghash-ce-glue.c | 8 +--
> > arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
> > arch/arm64/crypto/sha256-glue.c | 4 +-
> > arch/arm64/include/asm/cpufeature.h | 22 ++++----
> > arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++-
> > arch/arm64/include/uapi/asm/hwcap.h | 2 +-
> > arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------
> > arch/arm64/kernel/cpuinfo.c | 2 +-
> > arch/arm64/kernel/fpsimd.c | 4 +-
> > drivers/clocksource/arm_arch_timer.c | 8 +++
> > 14 files changed, 117 insertions(+), 60 deletions(-)
> >
>
> [...]
>
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index e505e1fbd2b9..f06e1da1d678 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -14,15 +14,8 @@
> > #include <asm/hwcap.h>
> > #include <asm/sysreg.h>
> >
> > -/*
> > - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally
> > - * in the kernel and for user space to keep track of which optional features
> > - * are supported by the current system. So let's map feature 'x' to HWCAP_x.
> > - * Note that HWCAP_x constants are bit fields so we need to take the log.
> > - */
> > -
> > -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
> > -#define cpu_feature(x) ilog2(HWCAP_ ## x)
> > +#define MAX_CPU_FEATURES 64
> > +#define cpu_feature(x) (KERNEL_HWCAP_ ## x)
>
> Nit: do we need the () here? They may be defensive, but I'm not sure
> they're required.
I guess not, checkpatch doesn't complain - I'll remove them.
>
> [...]
>
> > diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> > index 400b80b49595..d21fe3314d90 100644
> > --- a/arch/arm64/include/asm/hwcap.h
> > +++ b/arch/arm64/include/asm/hwcap.h
> > @@ -39,12 +39,59 @@
> > #define COMPAT_HWCAP2_SHA2 (1 << 3)
> > #define COMPAT_HWCAP2_CRC32 (1 << 4)
> >
> > +/*
> > + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
> > + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
> > + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here
> > + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart.
> > + *
> > + * Hwcaps should be set and tested within the kernel via the
> > + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix
> > + * of KERNEL_HWCAP_{feature}.
> > + */
> > +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP)
> > +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD)
> > +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM)
> > +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES)
> > +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL)
> > +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1)
> > +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2)
> > +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32)
> > +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS)
> > +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP)
> > +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP)
> > +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID)
> > +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM)
> > +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT)
> > +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA)
> > +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC)
> > +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP)
> > +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3)
> > +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3)
> > +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4)
> > +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP)
> > +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512)
> > +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE)
> > +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM)
> > +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT)
> > +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT)
> > +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC)
> > +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM)
> > +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS)
> > +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB)
> > +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA)
> > +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG)
> > +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32)
>
> Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out
> each time?
>
> If we are splitting ths CVADP support from this patch, then dropping
> such a wrapper macro here (maybe with a comment) will serve as a
> placeholder for whichever patch wins the race for the first HWCAP2
> flag.
>
> Say
>
> #define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32)
>
> (Optionally, we could also have __khwcap_feature() too so that
> everything looks nice and regular.)
Yes this makes sense, thanks for the suggestion.
>
> [...]
>
> > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > index aa4ec53281ce..6cc8aff83805 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > | ARCH_TIMER_VIRT_EVT_EN;
> > arch_timer_set_cntkctl(cntkctl);
> > +#ifdef CONFIG_ARM64
> > + cpu_set_named_feature(EVTSTRM);
> > +#else
> > elf_hwcap |= HWCAP_EVTSTRM;
> > +#endif
>
> I wonder whether we can have a generic definition for this:
>
> #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
You mean specific to arm32?
I will do this, along with a cpu_get_named_feature - but I think I'd prefer
to do this in a separate series.
>
> seems a reasonable fallback when the arch doesn't provide its own
> version.
>
>
> Although we don't have many instances, it would still be nice to avoid
> ifdeffery creeping in.
>
> [...]
>
> We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into
> this patch.
>
> It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt
> updates alongside this patch in the series (or even incorporate them
> into this patch, since they're not huge.)
Yes that's OK.
>
> Other than that, looks reasonable to me.
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-02 15:55 ` Dave Martin
@ 2019-04-03 8:53 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 8:53 UTC (permalink / raw)
To: Dave Martin
Cc: Suzuki K Poulose, mark.rutland, libc-alpha, Szabolcs.Nagy,
catalin.marinas, will.deacon, pb, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 04:55:58PM +0100, Dave Martin wrote:
> On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
> > Hi,
> >
> > On 02/04/2019 16:06, Andrew Murray wrote:
> > >On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> > >>On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> > >>>The introduction of AT_HWCAP2 introduced accessors which ensure that
> > >>>hwcap features are set and tested appropriately.
> > >>>
> > >>>Let's now mandate access to elf_hwcap via these accessors by making
> > >>>elf_hwcap static within cpufeature.c.
> > >>
> > >>Looks reasonable except for a couple of minor nits below.
> > >>
> > >>I had wondered whether putting these accessors out of line would affect
> > >>any hot paths, but I can't see these used from anything that looks like
> > >>a hot path. So we're probably fine.
> > >>
> > >>cpus_have_const_cap() is preferred for places where this matters,
> > >>anyway.
> >
> > Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
>
> Sure, I meant: where we need to test something fast, we can have a
> cpucap for it, rather than rely on the ELF hwcaps.
>
> In practice, we already follow this pattern today: ELF hwcap flags are
> tested in a few places, but I don't see anything that is fast-path.
>
> >
> > >>
> > >>[...]
> > >>
> > >>>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > >>>index 986ceeacd19f..84ca52fa75e5 100644
> > >>>--- a/arch/arm64/kernel/cpufeature.c
> > >>>+++ b/arch/arm64/kernel/cpufeature.c
> > >>>@@ -35,8 +35,7 @@
> > >>> #include <asm/traps.h>
> > >>> #include <asm/virt.h>
> > >>>-unsigned long elf_hwcap __read_mostly;
> > >>>-EXPORT_SYMBOL_GPL(elf_hwcap);
> > >>>+static unsigned long elf_hwcap __read_mostly;
> > >>
> > >>Now that this doesn't correspond directly to ELF_HWCAP any more and we
> > >>hide it, can we rename it to avoid confusion?
> > >>
> > >>Maybe "kernel_hwcap"?
> > >
> > >Yes this seems reasonable.
> >
> > nit:
> >
> > As mentioned above we have "cpu_hwcaps" for the features only internally
> > by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> > major purpose is for userspace consumption and could easily confuse with
> > the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
> >
> > How about "user_hwcaps" ? Or preferrably something closer to that.
>
> Yes, that may be better.
>
> Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
>
> Since kernel_hwcap is just a static variable now, maybe it's sufficient
> to stick a comment next to it explaining what it is (and what it isn't).
> "user_hwcaps" still implies that this might be the userspace view of the
> flags, which it isn't.
>
> But I don't feel strongly about this. If someone wants to make a
> decision, I'm happy to defer to it.
I think changing the name will cause more confusion - there isn't an obvious
name for it and needing a comment to explain it hints that this may not be
the best approach. As it's a static variable with only 4 uses in the same
file it should be pretty clear to anyone interested. Also keeping the same
name will help users find it and understand how it has changed if they
incorrectly attempt to use it by setting/testing bits on it.
Afterall the elf_hwcap variable does still hold the elf_hwcap bits and it's
obtained by cpu_get_elf_hwcap. The naming of KERNEL_HWCAP also makes sense
in this context.
Perhaps a better name would be something like elf_hwcaps implying that there
is some mapping required (though this would only last until we run out of
space in it and need another one).
Shall we stick with what we have?
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-03 8:53 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 8:53 UTC (permalink / raw)
To: Dave Martin
Cc: mark.rutland, libc-alpha, Suzuki K Poulose, Szabolcs.Nagy,
catalin.marinas, will.deacon, pb, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 04:55:58PM +0100, Dave Martin wrote:
> On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
> > Hi,
> >
> > On 02/04/2019 16:06, Andrew Murray wrote:
> > >On Tue, Apr 02, 2019 at 03:58:21PM +0100, Dave Martin wrote:
> > >>On Mon, Apr 01, 2019 at 11:45:11AM +0100, Andrew Murray wrote:
> > >>>The introduction of AT_HWCAP2 introduced accessors which ensure that
> > >>>hwcap features are set and tested appropriately.
> > >>>
> > >>>Let's now mandate access to elf_hwcap via these accessors by making
> > >>>elf_hwcap static within cpufeature.c.
> > >>
> > >>Looks reasonable except for a couple of minor nits below.
> > >>
> > >>I had wondered whether putting these accessors out of line would affect
> > >>any hot paths, but I can't see these used from anything that looks like
> > >>a hot path. So we're probably fine.
> > >>
> > >>cpus_have_const_cap() is preferred for places where this matters,
> > >>anyway.
> >
> > Btw, thats for cpu_hwcaps, which is completely different from elf_hwcaps.
>
> Sure, I meant: where we need to test something fast, we can have a
> cpucap for it, rather than rely on the ELF hwcaps.
>
> In practice, we already follow this pattern today: ELF hwcap flags are
> tested in a few places, but I don't see anything that is fast-path.
>
> >
> > >>
> > >>[...]
> > >>
> > >>>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > >>>index 986ceeacd19f..84ca52fa75e5 100644
> > >>>--- a/arch/arm64/kernel/cpufeature.c
> > >>>+++ b/arch/arm64/kernel/cpufeature.c
> > >>>@@ -35,8 +35,7 @@
> > >>> #include <asm/traps.h>
> > >>> #include <asm/virt.h>
> > >>>-unsigned long elf_hwcap __read_mostly;
> > >>>-EXPORT_SYMBOL_GPL(elf_hwcap);
> > >>>+static unsigned long elf_hwcap __read_mostly;
> > >>
> > >>Now that this doesn't correspond directly to ELF_HWCAP any more and we
> > >>hide it, can we rename it to avoid confusion?
> > >>
> > >>Maybe "kernel_hwcap"?
> > >
> > >Yes this seems reasonable.
> >
> > nit:
> >
> > As mentioned above we have "cpu_hwcaps" for the features only internally
> > by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> > major purpose is for userspace consumption and could easily confuse with
> > the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
> >
> > How about "user_hwcaps" ? Or preferrably something closer to that.
>
> Yes, that may be better.
>
> Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
>
> Since kernel_hwcap is just a static variable now, maybe it's sufficient
> to stick a comment next to it explaining what it is (and what it isn't).
> "user_hwcaps" still implies that this might be the userspace view of the
> flags, which it isn't.
>
> But I don't feel strongly about this. If someone wants to make a
> decision, I'm happy to defer to it.
I think changing the name will cause more confusion - there isn't an obvious
name for it and needing a comment to explain it hints that this may not be
the best approach. As it's a static variable with only 4 uses in the same
file it should be pretty clear to anyone interested. Also keeping the same
name will help users find it and understand how it has changed if they
incorrectly attempt to use it by setting/testing bits on it.
Afterall the elf_hwcap variable does still hold the elf_hwcap bits and it's
obtained by cpu_get_elf_hwcap. The naming of KERNEL_HWCAP also makes sense
in this context.
Perhaps a better name would be something like elf_hwcaps implying that there
is some mapping required (though this would only last until we run out of
space in it and need another one).
Shall we stick with what we have?
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-03 8:32 ` Andrew Murray
@ 2019-04-03 9:11 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:11 UTC (permalink / raw)
To: Andrew Murray
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> > On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
[...]
> > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > > index aa4ec53281ce..6cc8aff83805 100644
> > > --- a/drivers/clocksource/arm_arch_timer.c
> > > +++ b/drivers/clocksource/arm_arch_timer.c
> > > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > > | ARCH_TIMER_VIRT_EVT_EN;
> > > arch_timer_set_cntkctl(cntkctl);
> > > +#ifdef CONFIG_ARM64
> > > + cpu_set_named_feature(EVTSTRM);
> > > +#else
> > > elf_hwcap |= HWCAP_EVTSTRM;
> > > +#endif
> >
> > I wonder whether we can have a generic definition for this:
> >
> > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
>
> You mean specific to arm32?
>
> I will do this, along with a cpu_get_named_feature - but I think I'd prefer
> to do this in a separate series.
Yes, we could do that. We could also do it more widely, but it's
probably not worth the overhead of doing it.
[...]
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-03 9:11 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:11 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> > On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
[...]
> > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > > index aa4ec53281ce..6cc8aff83805 100644
> > > --- a/drivers/clocksource/arm_arch_timer.c
> > > +++ b/drivers/clocksource/arm_arch_timer.c
> > > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > > | ARCH_TIMER_VIRT_EVT_EN;
> > > arch_timer_set_cntkctl(cntkctl);
> > > +#ifdef CONFIG_ARM64
> > > + cpu_set_named_feature(EVTSTRM);
> > > +#else
> > > elf_hwcap |= HWCAP_EVTSTRM;
> > > +#endif
> >
> > I wonder whether we can have a generic definition for this:
> >
> > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
>
> You mean specific to arm32?
>
> I will do this, along with a cpu_get_named_feature - but I think I'd prefer
> to do this in a separate series.
Yes, we could do that. We could also do it more widely, but it's
probably not worth the overhead of doing it.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
2019-04-03 8:53 ` Andrew Murray
@ 2019-04-03 9:13 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:13 UTC (permalink / raw)
To: Andrew Murray
Cc: Suzuki K Poulose, mark.rutland, libc-alpha, Szabolcs.Nagy,
catalin.marinas, will.deacon, pb, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 09:53:26AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 04:55:58PM +0100, Dave Martin wrote:
> > On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
[...]
> > > nit:
> > >
> > > As mentioned above we have "cpu_hwcaps" for the features only internally
> > > by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> > > major purpose is for userspace consumption and could easily confuse with
> > > the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
> > >
> > > How about "user_hwcaps" ? Or preferrably something closer to that.
> >
> > Yes, that may be better.
> >
> > Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
> >
> > Since kernel_hwcap is just a static variable now, maybe it's sufficient
> > to stick a comment next to it explaining what it is (and what it isn't).
> > "user_hwcaps" still implies that this might be the userspace view of the
> > flags, which it isn't.
> >
> > But I don't feel strongly about this. If someone wants to make a
> > decision, I'm happy to defer to it.
>
> I think changing the name will cause more confusion - there isn't an obvious
> name for it and needing a comment to explain it hints that this may not be
> the best approach. As it's a static variable with only 4 uses in the same
> file it should be pretty clear to anyone interested. Also keeping the same
> name will help users find it and understand how it has changed if they
> incorrectly attempt to use it by setting/testing bits on it.
>
> Afterall the elf_hwcap variable does still hold the elf_hwcap bits and it's
> obtained by cpu_get_elf_hwcap. The naming of KERNEL_HWCAP also makes sense
> in this context.
>
> Perhaps a better name would be something like elf_hwcaps implying that there
> is some mapping required (though this would only last until we run out of
> space in it and need another one).
>
> Shall we stick with what we have?
I'm happy enough with what you propose: I agree, there's not an
obviously a better name, and now that this is local, the scope for
confusion is lessened. So, add a comment, but keep whetever name you're
happy with.
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap
@ 2019-04-03 9:13 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:13 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland, libc-alpha, Suzuki K Poulose, Szabolcs.Nagy,
catalin.marinas, will.deacon, pb, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 09:53:26AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 04:55:58PM +0100, Dave Martin wrote:
> > On Tue, Apr 02, 2019 at 04:32:57PM +0100, Suzuki K Poulose wrote:
[...]
> > > nit:
> > >
> > > As mentioned above we have "cpu_hwcaps" for the features only internally
> > > by the kernel. Naming it "kernel_hwcap" kind of looses the hint that the
> > > major purpose is for userspace consumption and could easily confuse with
> > > the poorly named "cpu_hwcaps" which should have been called kernel_hwcaps.
> > >
> > > How about "user_hwcaps" ? Or preferrably something closer to that.
> >
> > Yes, that may be better.
> >
> > Of course, we also have this naming in all the KERNEL_HWCAP #defined now.
> >
> > Since kernel_hwcap is just a static variable now, maybe it's sufficient
> > to stick a comment next to it explaining what it is (and what it isn't).
> > "user_hwcaps" still implies that this might be the userspace view of the
> > flags, which it isn't.
> >
> > But I don't feel strongly about this. If someone wants to make a
> > decision, I'm happy to defer to it.
>
> I think changing the name will cause more confusion - there isn't an obvious
> name for it and needing a comment to explain it hints that this may not be
> the best approach. As it's a static variable with only 4 uses in the same
> file it should be pretty clear to anyone interested. Also keeping the same
> name will help users find it and understand how it has changed if they
> incorrectly attempt to use it by setting/testing bits on it.
>
> Afterall the elf_hwcap variable does still hold the elf_hwcap bits and it's
> obtained by cpu_get_elf_hwcap. The naming of KERNEL_HWCAP also makes sense
> in this context.
>
> Perhaps a better name would be something like elf_hwcaps implying that there
> is some mapping required (though this would only last until we run out of
> space in it and need another one).
>
> Shall we stick with what we have?
I'm happy enough with what you propose: I agree, there's not an
obviously a better name, and now that this is local, the scope for
confusion is lessened. So, add a comment, but keep whetever name you're
happy with.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
2019-04-02 14:59 ` Dave Martin
@ 2019-04-03 9:23 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:23 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
>
> Do you mean ARM64_HAS_DCPODP?
Yes I did - good catch.
>
> And do we need this? This capability flag doesn't currently appear to
> be used for anything (which makes me wonder whether it _should_ be wired
> up to something in the kernel).
>
> Do we expect the kernel to do something special with this in the future?
>
> OTOH, we get a nice printk when the feature is detected, and the code
> size cost is insignificant. So, if there's a reasonable expectation that
> we will use it someday, I don't see a big problem with having it.
Yes it's not currently used, so I'm happy to drop this patch if people prefer
that - however it does complement the existing DCPOP cap which is present.
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
>
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 9 +++++++++
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > index f6a76e43f39e..defdc67d9ab4 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b/arch/arm64/include/asm/cpucaps.h
> > @@ -61,7 +61,8 @@
> > #define ARM64_HAS_GENERIC_AUTH_ARCH 40
> > #define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
> > #define ARM64_HAS_IRQ_PRIO_MASKING 42
> > +#define ARM64_HAS_DCPODP 43
> >
> > -#define ARM64_NCAPS 43
> > +#define ARM64_NCAPS 44
> >
> > #endif /* __ASM_CPUCAPS_H */
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 5e27d2dbe45e..c74b25895c43 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> > .min_field_value = 1,
> > },
> > + {
> > + .desc = "Data cache clean to Point of Deep Persistence",
> > + .capability = ARM64_HAS_DCPODP,
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .matches = has_cpuid_feature,
> > + .sys_reg = SYS_ID_AA64ISAR1_EL1,
> > + .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> > + .min_field_value = 2,
> > + },
> > #endif
> > #ifdef CONFIG_ARM64_SVE
> > {
> > --
> > 2.21.0
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
@ 2019-04-03 9:23 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:23 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
>
> Do you mean ARM64_HAS_DCPODP?
Yes I did - good catch.
>
> And do we need this? This capability flag doesn't currently appear to
> be used for anything (which makes me wonder whether it _should_ be wired
> up to something in the kernel).
>
> Do we expect the kernel to do something special with this in the future?
>
> OTOH, we get a nice printk when the feature is detected, and the code
> size cost is insignificant. So, if there's a reasonable expectation that
> we will use it someday, I don't see a big problem with having it.
Yes it's not currently used, so I'm happy to drop this patch if people prefer
that - however it does complement the existing DCPOP cap which is present.
Thanks,
Andrew Murray
>
> Cheers
> ---Dave
>
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 9 +++++++++
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > index f6a76e43f39e..defdc67d9ab4 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b/arch/arm64/include/asm/cpucaps.h
> > @@ -61,7 +61,8 @@
> > #define ARM64_HAS_GENERIC_AUTH_ARCH 40
> > #define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
> > #define ARM64_HAS_IRQ_PRIO_MASKING 42
> > +#define ARM64_HAS_DCPODP 43
> >
> > -#define ARM64_NCAPS 43
> > +#define ARM64_NCAPS 44
> >
> > #endif /* __ASM_CPUCAPS_H */
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 5e27d2dbe45e..c74b25895c43 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1339,6 +1339,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> > .min_field_value = 1,
> > },
> > + {
> > + .desc = "Data cache clean to Point of Deep Persistence",
> > + .capability = ARM64_HAS_DCPODP,
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .matches = has_cpuid_feature,
> > + .sys_reg = SYS_ID_AA64ISAR1_EL1,
> > + .field_pos = ID_AA64ISAR1_DPB_SHIFT,
> > + .min_field_value = 2,
> > + },
> > #endif
> > #ifdef CONFIG_ARM64_SVE
> > {
> > --
> > 2.21.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-03 9:11 ` Dave Martin
@ 2019-04-03 9:29 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:29 UTC (permalink / raw)
To: Dave Martin
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Wed, Apr 03, 2019 at 10:11:20AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> > On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> > > On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
>
> [...]
>
> > > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > > > index aa4ec53281ce..6cc8aff83805 100644
> > > > --- a/drivers/clocksource/arm_arch_timer.c
> > > > +++ b/drivers/clocksource/arm_arch_timer.c
> > > > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > > > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > > > | ARCH_TIMER_VIRT_EVT_EN;
> > > > arch_timer_set_cntkctl(cntkctl);
> > > > +#ifdef CONFIG_ARM64
> > > > + cpu_set_named_feature(EVTSTRM);
> > > > +#else
> > > > elf_hwcap |= HWCAP_EVTSTRM;
> > > > +#endif
> > >
> > > I wonder whether we can have a generic definition for this:
> > >
> > > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
> >
> > You mean specific to arm32?
> >
> > I will do this, along with a cpu_get_named_feature - but I think I'd prefer
> > to do this in a separate series.
>
> Yes, we could do that. We could also do it more widely, but it's
> probably not worth the overhead of doing it.
I had considered this as well but also determined that it wouldn't give
much gain.
Thanks,
Andrew Murray
>
> [...]
>
> Cheers
> ---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-03 9:29 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:29 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 10:11:20AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> > On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
> > > On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote:
>
> [...]
>
> > > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > > > index aa4ec53281ce..6cc8aff83805 100644
> > > > --- a/drivers/clocksource/arm_arch_timer.c
> > > > +++ b/drivers/clocksource/arm_arch_timer.c
> > > > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider)
> > > > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> > > > | ARCH_TIMER_VIRT_EVT_EN;
> > > > arch_timer_set_cntkctl(cntkctl);
> > > > +#ifdef CONFIG_ARM64
> > > > + cpu_set_named_feature(EVTSTRM);
> > > > +#else
> > > > elf_hwcap |= HWCAP_EVTSTRM;
> > > > +#endif
> > >
> > > I wonder whether we can have a generic definition for this:
> > >
> > > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
> >
> > You mean specific to arm32?
> >
> > I will do this, along with a cpu_get_named_feature - but I think I'd prefer
> > to do this in a separate series.
>
> Yes, we could do that. We could also do it more widely, but it's
> probably not worth the overhead of doing it.
I had considered this as well but also determined that it wouldn't give
much gain.
Thanks,
Andrew Murray
>
> [...]
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
2019-04-03 9:23 ` Andrew Murray
@ 2019-04-03 9:32 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:32 UTC (permalink / raw)
To: Andrew Murray
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Wed, Apr 03, 2019 at 10:23:42AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> > On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
> >
> > Do you mean ARM64_HAS_DCPODP?
>
> Yes I did - good catch.
>
> >
> > And do we need this? This capability flag doesn't currently appear to
> > be used for anything (which makes me wonder whether it _should_ be wired
> > up to something in the kernel).
> >
> > Do we expect the kernel to do something special with this in the future?
> >
> > OTOH, we get a nice printk when the feature is detected, and the code
> > size cost is insignificant. So, if there's a reasonable expectation that
> > we will use it someday, I don't see a big problem with having it.
>
> Yes it's not currently used, so I'm happy to drop this patch if people prefer
> that - however it does complement the existing DCPOP cap which is present.
OK, sounds fine.
Maybe add a note in the commit message that this is here for consistency
with DCPOP, and we anticipate it being used in the future.
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
@ 2019-04-03 9:32 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:32 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 10:23:42AM +0100, Andrew Murray wrote:
> On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> > On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
> >
> > Do you mean ARM64_HAS_DCPODP?
>
> Yes I did - good catch.
>
> >
> > And do we need this? This capability flag doesn't currently appear to
> > be used for anything (which makes me wonder whether it _should_ be wired
> > up to something in the kernel).
> >
> > Do we expect the kernel to do something special with this in the future?
> >
> > OTOH, we get a nice printk when the feature is detected, and the code
> > size cost is insignificant. So, if there's a reasonable expectation that
> > we will use it someday, I don't see a big problem with having it.
>
> Yes it's not currently used, so I'm happy to drop this patch if people prefer
> that - however it does complement the existing DCPOP cap which is present.
OK, sounds fine.
Maybe add a note in the commit message that this is here for consistency
with DCPOP, and we anticipate it being used in the future.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
2019-04-03 9:29 ` Andrew Murray
@ 2019-04-03 9:35 ` Dave Martin
-1 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:35 UTC (permalink / raw)
To: Andrew Murray
Cc: Catalin Marinas, Will Deacon, Szabolcs Nagy, linux-arm-kernel,
Mark Rutland, Phil Blundell, libc-alpha, linux-api
On Wed, Apr 03, 2019 at 10:29:52AM +0100, Andrew Murray wrote:
> On Wed, Apr 03, 2019 at 10:11:20AM +0100, Dave Martin wrote:
> > On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> > > On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
[...]
> > > > I wonder whether we can have a generic definition for this:
> > > >
> > > > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
> > >
> > > You mean specific to arm32?
> > >
> > > I will do this, along with a cpu_get_named_feature - but I think
> > > I'd prefer to do this in a separate series.
> >
> > Yes, we could do that. We could also do it more widely, but it's
> > probably not worth the overhead of doing it.
>
> I had considered this as well but also determined that it wouldn't give
> much gain.
Yep, agreed. It can always be done later if it turns out to be useful
for someone.
Cheers
---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2
@ 2019-04-03 9:35 ` Dave Martin
0 siblings, 0 replies; 46+ messages in thread
From: Dave Martin @ 2019-04-03 9:35 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 10:29:52AM +0100, Andrew Murray wrote:
> On Wed, Apr 03, 2019 at 10:11:20AM +0100, Dave Martin wrote:
> > On Wed, Apr 03, 2019 at 09:32:55AM +0100, Andrew Murray wrote:
> > > On Tue, Apr 02, 2019 at 03:58:31PM +0100, Dave Martin wrote:
[...]
> > > > I wonder whether we can have a generic definition for this:
> > > >
> > > > #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x)
> > >
> > > You mean specific to arm32?
> > >
> > > I will do this, along with a cpu_get_named_feature - but I think
> > > I'd prefer to do this in a separate series.
> >
> > Yes, we could do that. We could also do it more widely, but it's
> > probably not worth the overhead of doing it.
>
> I had considered this as well but also determined that it wouldn't give
> much gain.
Yep, agreed. It can always be done later if it turns out to be useful
for someone.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
2019-04-03 9:32 ` Dave Martin
@ 2019-04-03 9:57 ` Andrew Murray
-1 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:57 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 10:32:43AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 10:23:42AM +0100, Andrew Murray wrote:
> > On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> > > On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > > > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
> > >
> > > Do you mean ARM64_HAS_DCPODP?
> >
> > Yes I did - good catch.
> >
> > >
> > > And do we need this? This capability flag doesn't currently appear to
> > > be used for anything (which makes me wonder whether it _should_ be wired
> > > up to something in the kernel).
> > >
> > > Do we expect the kernel to do something special with this in the future?
> > >
> > > OTOH, we get a nice printk when the feature is detected, and the code
> > > size cost is insignificant. So, if there's a reasonable expectation that
> > > we will use it someday, I don't see a big problem with having it.
> >
> > Yes it's not currently used, so I'm happy to drop this patch if people prefer
> > that - however it does complement the existing DCPOP cap which is present.
>
> OK, sounds fine.
>
> Maybe add a note in the commit message that this is here for consistency
> with DCPOP, and we anticipate it being used in the future.
OK thanks,
Andrew Murray
>
> Cheers
> ---Dave
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature
@ 2019-04-03 9:57 ` Andrew Murray
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Murray @ 2019-04-03 9:57 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, libc-alpha, Szabolcs Nagy, Catalin Marinas,
Will Deacon, Phil Blundell, linux-api, linux-arm-kernel
On Wed, Apr 03, 2019 at 10:32:43AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 10:23:42AM +0100, Andrew Murray wrote:
> > On Tue, Apr 02, 2019 at 03:59:58PM +0100, Dave Martin wrote:
> > > On Mon, Apr 01, 2019 at 11:45:14AM +0100, Andrew Murray wrote:
> > > > Advertise ARM64_HAS_DCPOP when both DC CVAP and DC CVADP are supported.
> > >
> > > Do you mean ARM64_HAS_DCPODP?
> >
> > Yes I did - good catch.
> >
> > >
> > > And do we need this? This capability flag doesn't currently appear to
> > > be used for anything (which makes me wonder whether it _should_ be wired
> > > up to something in the kernel).
> > >
> > > Do we expect the kernel to do something special with this in the future?
> > >
> > > OTOH, we get a nice printk when the feature is detected, and the code
> > > size cost is insignificant. So, if there's a reasonable expectation that
> > > we will use it someday, I don't see a big problem with having it.
> >
> > Yes it's not currently used, so I'm happy to drop this patch if people prefer
> > that - however it does complement the existing DCPOP cap which is present.
>
> OK, sounds fine.
>
> Maybe add a note in the commit message that this is here for consistency
> with DCPOP, and we anticipate it being used in the future.
OK thanks,
Andrew Murray
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2019-04-03 9:57 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-01 10:45 [PATCH v3 0/7] arm64: Initial support for CVADP Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-01 10:45 ` [PATCH v3 1/7] arm64: Handle trapped DC CVADP Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-01 10:45 ` [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2 Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-02 14:58 ` Dave Martin
2019-04-02 14:58 ` Dave Martin
2019-04-03 8:32 ` Andrew Murray
2019-04-03 8:32 ` Andrew Murray
2019-04-03 9:11 ` Dave Martin
2019-04-03 9:11 ` Dave Martin
2019-04-03 9:29 ` Andrew Murray
2019-04-03 9:29 ` Andrew Murray
2019-04-03 9:35 ` Dave Martin
2019-04-03 9:35 ` Dave Martin
2019-04-01 10:45 ` [PATCH v3 3/7] arm64: HWCAP: encapsulate elf_hwcap Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-02 14:58 ` Dave Martin
2019-04-02 14:58 ` Dave Martin
2019-04-02 15:06 ` Andrew Murray
2019-04-02 15:06 ` Andrew Murray
2019-04-02 15:32 ` Suzuki K Poulose
2019-04-02 15:32 ` Suzuki K Poulose
2019-04-02 15:55 ` Dave Martin
2019-04-02 15:55 ` Dave Martin
2019-04-03 8:53 ` Andrew Murray
2019-04-03 8:53 ` Andrew Murray
2019-04-03 9:13 ` Dave Martin
2019-04-03 9:13 ` Dave Martin
2019-04-01 10:45 ` [PATCH v3 4/7] arm64: Expose DC CVADP to userspace Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-01 10:45 ` [PATCH v3 5/7] arm64: add CVADP support to the cache maintenance helper Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-01 10:45 ` [PATCH v3 6/7] arm64: Advertise ARM64_HAS_DCPODP cpu feature Andrew Murray
2019-04-01 10:45 ` Andrew Murray
2019-04-02 14:59 ` Dave Martin
2019-04-02 14:59 ` Dave Martin
2019-04-03 9:23 ` Andrew Murray
2019-04-03 9:23 ` Andrew Murray
2019-04-03 9:32 ` Dave Martin
2019-04-03 9:32 ` Dave Martin
2019-04-03 9:57 ` Andrew Murray
2019-04-03 9:57 ` Andrew Murray
2019-04-01 10:45 ` [PATCH v3 7/7] arm64: docs: document AT_HWCAP2 and unused AT_HWCAP bits Andrew Murray
2019-04-01 10:45 ` Andrew Murray
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.