Re: [PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths

2017-08-17 Thread Suzuki K Poulose 

On 17/08/17 11:04, Dave Martin wrote:

On Wed, Aug 16, 2017 at 06:48:01PM +0100, Suzuki K Poulose wrote:

On 09/08/17 13:05, Dave Martin wrote:

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]


Any idea what this is ^ ?  I don't know if this is caused by me or you,
but I only seem to see it on subthreads you've replied to.



Dave,

Sorry about that, should have trimmed that. It looks like the mail server is 
unhappy
about email received via kvmarm list and I don't know why.




+void __init sve_setup(void)
+{
+   u64 zcr;
+   unsigned int max_vl;
+
+   if (!system_supports_sve())
+   return;
+
+   /*
+* The architecture mandates 128-bit vectors be supported, and
+* the code assumes elsewhere that sve_vq_map is non-empty:
+*/
+   BUG_ON(!test_bit(vq_to_bit(1), sve_vq_map));
+
+   sve_vq_map_finalised = true;


We have something local in cpufeature.c, sys_caps_initialised. May be we could
reuse it here ? With or without that change, FWIW.


I'll take a look at that.  Inventing that here seemed a little ugly, and
this is all driven from the cpufreatures code anyway now which ensures a
certain ordering.

If I can reuse sys_caps_initialised for this, I will -- seems pointless
to reinvent it.


Suzuki

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths

2017-08-17 Thread Dave Martin 
On Wed, Aug 16, 2017 at 06:48:01PM +0100, Suzuki K Poulose wrote:
> On 09/08/17 13:05, Dave Martin wrote:
> >[This sender failed our fraud detection checks and may not be who they 
> >appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Any idea what this is ^ ?  I don't know if this is caused by me or you,
but I only seem to see it on subthreads you've replied to.

> >This patch uses the cpufeatures framework to determine common SVE
> >capabilities and vector lengths, and configures the runtime SVE
> >support code appropriately.
> >
> >ZCR_ELx is not really a feature register, but it is convenient to
> >use it as a template for recording the maximum vector length
> >supported by a CPU, using the LEN field.  This field is similar to
> >a feature field in that it is a contiguous bitfield for which we
> >want to determine the minimum system-wide value.  This patch adds
> >ZCR as a pseudo-register in cpuinfo/cpufeatures, with appropriate
> >custom code to populate it.  Finding the minimum supported value of
> >the LEN field is left to the cpufeatures framework in the usual
> >way.
> >
> >The meaning of ID_AA64ZFR0_EL1 is not architecturally defined yet,
> >so for now we just require it to be zero.
> >
> >Note that much of this code is dormant and SVE still won't be used
> >yet, since system_supports_sve() remains hardwired to false.
> >
> >Signed-off-by: Dave Martin 
> 
> Dave,
> 
> The cpufeature bits look good to me, with one minor comment.
> 
> 
> >diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> >index bce95de..955c873 100644
> >--- a/arch/arm64/kernel/fpsimd.c
> >+++ b/arch/arm64/kernel/fpsimd.c
> 
> ...
> 
> >+void __init sve_setup(void)
> >+{
> >+   u64 zcr;
> >+   unsigned int max_vl;
> >+
> >+   if (!system_supports_sve())
> >+   return;
> >+
> >+   /*
> >+* The architecture mandates 128-bit vectors be supported, and
> >+* the code assumes elsewhere that sve_vq_map is non-empty:
> >+*/
> >+   BUG_ON(!test_bit(vq_to_bit(1), sve_vq_map));
> >+
> >+   sve_vq_map_finalised = true;
> 
> We have something local in cpufeature.c, sys_caps_initialised. May be we could
> reuse it here ? With or without that change, FWIW.

I'll take a look at that.  Inventing that here seemed a little ugly, and
this is all driven from the cpufreatures code anyway now which ensures a
certain ordering.

If I can reuse sys_caps_initialised for this, I will -- seems pointless
to reinvent it.

> Acked-by: Suzuki K Poulose 

Thanks
---Dave
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths

2017-08-16 Thread Suzuki K Poulose 

On 09/08/17 13:05, Dave Martin wrote:

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

This patch uses the cpufeatures framework to determine common SVE
capabilities and vector lengths, and configures the runtime SVE
support code appropriately.

ZCR_ELx is not really a feature register, but it is convenient to
use it as a template for recording the maximum vector length
supported by a CPU, using the LEN field.  This field is similar to
a feature field in that it is a contiguous bitfield for which we
want to determine the minimum system-wide value.  This patch adds
ZCR as a pseudo-register in cpuinfo/cpufeatures, with appropriate
custom code to populate it.  Finding the minimum supported value of
the LEN field is left to the cpufeatures framework in the usual
way.

The meaning of ID_AA64ZFR0_EL1 is not architecturally defined yet,
so for now we just require it to be zero.

Note that much of this code is dormant and SVE still won't be used
yet, since system_supports_sve() remains hardwired to false.

Signed-off-by: Dave Martin 


Dave,

The cpufeature bits look good to me, with one minor comment.



diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index bce95de..955c873 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c


...


+void __init sve_setup(void)
+{
+   u64 zcr;
+   unsigned int max_vl;
+
+   if (!system_supports_sve())
+   return;
+
+   /*
+* The architecture mandates 128-bit vectors be supported, and
+* the code assumes elsewhere that sve_vq_map is non-empty:
+*/
+   BUG_ON(!test_bit(vq_to_bit(1), sve_vq_map));
+
+   sve_vq_map_finalised = true;


We have something local in cpufeature.c, sys_caps_initialised. May be we could
reuse it here ? With or without that change, FWIW.

Acked-by: Suzuki K Poulose 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths

2017-08-09 Thread Dave Martin 
This patch uses the cpufeatures framework to determine common SVE
capabilities and vector lengths, and configures the runtime SVE
support code appropriately.

ZCR_ELx is not really a feature register, but it is convenient to
use it as a template for recording the maximum vector length
supported by a CPU, using the LEN field.  This field is similar to
a feature field in that it is a contiguous bitfield for which we
want to determine the minimum system-wide value.  This patch adds
ZCR as a pseudo-register in cpuinfo/cpufeatures, with appropriate
custom code to populate it.  Finding the minimum supported value of
the LEN field is left to the cpufeatures framework in the usual
way.

The meaning of ID_AA64ZFR0_EL1 is not architecturally defined yet,
so for now we just require it to be zero.

Note that much of this code is dormant and SVE still won't be used
yet, since system_supports_sve() remains hardwired to false.

Signed-off-by: Dave Martin 
---
 arch/arm64/include/asm/cpu.h|   4 ++
 arch/arm64/include/asm/cpufeature.h |  28 ++
 arch/arm64/include/asm/fpsimd.h |  10 
 arch/arm64/kernel/cpufeature.c  |  48 
 arch/arm64/kernel/cpuinfo.c |   6 ++
 arch/arm64/kernel/fpsimd.c  | 108 
 6 files changed, 204 insertions(+)

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index 889226b..8839227 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -41,6 +41,7 @@ struct cpuinfo_arm64 {
u64 reg_id_aa64mmfr2;
u64 reg_id_aa64pfr0;
u64 reg_id_aa64pfr1;
+   u64 reg_id_aa64zfr0;
 
u32 reg_id_dfr0;
u32 reg_id_isar0;
@@ -59,6 +60,9 @@ struct cpuinfo_arm64 {
u32 reg_mvfr0;
u32 reg_mvfr1;
u32 reg_mvfr2;
+
+   /* pseudo-ZCR for recording maximum ZCR_EL1 LEN value: */
+   u64 reg_zcr;
 };
 
 DECLARE_PER_CPU(struct cpuinfo_arm64, cpu_data);
diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 4ea3441..05eec27 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -10,6 +10,7 @@
 #define __ASM_CPUFEATURE_H
 
 #include 
+#include 
 #include 
 #include 
 
@@ -223,6 +224,13 @@ static inline bool id_aa64pfr0_32bit_el0(u64 pfr0)
return val == ID_AA64PFR0_EL0_32BIT_64BIT;
 }
 
+static inline bool id_aa64pfr0_sve(u64 pfr0)
+{
+   u32 val = cpuid_feature_extract_unsigned_field(pfr0, 
ID_AA64PFR0_SVE_SHIFT);
+
+   return val > 0;
+}
+
 void __init setup_cpu_features(void);
 
 void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
@@ -267,6 +275,26 @@ static inline bool system_supports_sve(void)
return false;
 }
 
+/*
+ * Read the pseudo-ZCR used by cpufeatures to identify the supported SVE
+ * vector length.
+ * Use only if SVE is present.  This function clobbers the SVE vector length.
+ */
+static u64 __maybe_unused read_zcr_features(void)
+{
+   u64 zcr;
+   unsigned int vq_max;
+
+   write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL1);
+
+   zcr = read_sysreg_s(SYS_ZCR_EL1);
+   zcr &= ~(u64)ZCR_ELx_LEN_MASK;
+   vq_max = sve_get_vl() / 16;
+   zcr |= vq_max - 1;
+
+   return zcr;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 39b26d2..f43f573 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -90,12 +90,22 @@ extern void fpsimd_dup_sve(struct task_struct *dst,
 extern int sve_set_vector_length(struct task_struct *task,
 unsigned long vl, unsigned long flags);
 
+extern void __init sve_init_vq_map(void);
+extern void sve_update_vq_map(void);
+extern int sve_verify_vq_map(void);
+extern void __init sve_setup(void);
+
 #else /* ! CONFIG_ARM64_SVE */
 
 static void __maybe_unused sve_alloc(struct task_struct *task) { }
 static void __maybe_unused fpsimd_release_thread(struct task_struct *task) { }
 static void __maybe_unused fpsimd_dup_sve(struct task_struct *dst,
  struct task_struct const *src) { }
+static void __maybe_unused sve_init_vq_map(void) { }
+static void __maybe_unused sve_update_vq_map(void) { }
+static int __maybe_unused sve_verify_vq_map(void) { return 0; }
+static void __maybe_unused sve_setup(void) { }
+
 #endif /* ! CONFIG_ARM64_SVE */
 
 /* For use by EFI runtime services calls only */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9f9e0064..f322c90 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -267,6 +268,12 @@ static const struct arm64_ftr_bits ftr_id_dfr0[] = {