diff mbox

[v2,16/22] arm64/debug: Make use of the system wide safe value

Message ID 1444064531-25607-17-git-send-email-suzuki.poulose@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Suzuki K Poulose Oct. 5, 2015, 5:02 p.m. UTC
Use the system wide value of ID_AA64DFR0 to make safer decisions

Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/include/asm/hw_breakpoint.h |    9 +++++++--
 arch/arm64/kernel/debug-monitors.c     |    6 ++++--
 2 files changed, 11 insertions(+), 4 deletions(-)

Comments

Catalin Marinas Oct. 8, 2015, 11:11 a.m. UTC | #1
On Mon, Oct 05, 2015 at 06:02:05PM +0100, Suzuki K. Poulose wrote:
> @@ -137,13 +138,17 @@ extern struct pmu perf_ops_bp;
>  /* Determine number of BRP registers available. */
>  static inline int get_num_brps(void)
>  {
> -	return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
> +	return 1 +
> +		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
> +						ID_AA64DFR0_BRPS_SHIFT);
>  }

cpuid_feature_extract_field() is fine but we should we bother with
read_system_reg vs just read_cpuid?

Similar question for patch 17/22.
Suzuki K Poulose Oct. 8, 2015, 11:56 a.m. UTC | #2
On 08/10/15 12:11, Catalin Marinas wrote:
> On Mon, Oct 05, 2015 at 06:02:05PM +0100, Suzuki K. Poulose wrote:
>> @@ -137,13 +138,17 @@ extern struct pmu perf_ops_bp;
>>   /* Determine number of BRP registers available. */
>>   static inline int get_num_brps(void)
>>   {
>> -	return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
>> +	return 1 +
>> +		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
>> +						ID_AA64DFR0_BRPS_SHIFT);
>>   }
>
> cpuid_feature_extract_field() is fine but we should we bother with
> read_system_reg vs just read_cpuid?
> Similar question for patch 17/22.

Well, we would have already TAINTed the kernel, if these fields are different.
It is just the matter of, whether we want to provide the safer value on a tainted
kernel or not. I am open to suggestions.


Thanks
Suzuki
Catalin Marinas Oct. 8, 2015, 3:08 p.m. UTC | #3
On Thu, Oct 08, 2015 at 12:56:28PM +0100, Suzuki K. Poulose wrote:
> On 08/10/15 12:11, Catalin Marinas wrote:
> >On Mon, Oct 05, 2015 at 06:02:05PM +0100, Suzuki K. Poulose wrote:
> >>@@ -137,13 +138,17 @@ extern struct pmu perf_ops_bp;
> >>  /* Determine number of BRP registers available. */
> >>  static inline int get_num_brps(void)
> >>  {
> >>-	return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
> >>+	return 1 +
> >>+		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
> >>+						ID_AA64DFR0_BRPS_SHIFT);
> >>  }
> >
> >cpuid_feature_extract_field() is fine but we should we bother with
> >read_system_reg vs just read_cpuid?
> >Similar question for patch 17/22.
> 
> Well, we would have already TAINTed the kernel, if these fields are different.
> It is just the matter of, whether we want to provide the safer value on a tainted
> kernel or not. I am open to suggestions.

Ah, sorry, I mixed read_system_reg() with read_cpu_sysreg(). I think we
need to rename the latter as it gets confusing. Maybe something like
read_native_sys_reg() or __raw_read_system_reg().
Suzuki K Poulose Oct. 8, 2015, 3:57 p.m. UTC | #4
On 08/10/15 16:08, Catalin Marinas wrote:
> On Thu, Oct 08, 2015 at 12:56:28PM +0100, Suzuki K. Poulose wrote:
>> On 08/10/15 12:11, Catalin Marinas wrote:
>>> On Mon, Oct 05, 2015 at 06:02:05PM +0100, Suzuki K. Poulose wrote:
>>>> @@ -137,13 +138,17 @@ extern struct pmu perf_ops_bp;
>>>>   /* Determine number of BRP registers available. */
>>>>   static inline int get_num_brps(void)
>>>>   {
>>>> -	return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
>>>> +	return 1 +
>>>> +		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
>>>> +						ID_AA64DFR0_BRPS_SHIFT);
>>>>   }
>>>
>>> cpuid_feature_extract_field() is fine but we should we bother with
>>> read_system_reg vs just read_cpuid?
>>> Similar question for patch 17/22.
>>
>> Well, we would have already TAINTed the kernel, if these fields are different.
>> It is just the matter of, whether we want to provide the safer value on a tainted
>> kernel or not. I am open to suggestions.
>
> Ah, sorry, I mixed read_system_reg() with read_cpu_sysreg(). I think we

Oh, ok. I think we should rename it as you suggest below to avoid the
confusion.

> need to rename the latter as it gets confusing. Maybe something like
> read_native_sys_reg() or __raw_read_system_reg().
>


Thanks
Suzuki
diff mbox

Patch

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 4c47cb2..e54415e 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -17,6 +17,7 @@ 
 #define __ASM_HW_BREAKPOINT_H
 
 #include <asm/cputype.h>
+#include <asm/cpufeature.h>
 
 #ifdef __KERNEL__
 
@@ -137,13 +138,17 @@  extern struct pmu perf_ops_bp;
 /* Determine number of BRP registers available. */
 static inline int get_num_brps(void)
 {
-	return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
+	return 1 +
+		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
+						ID_AA64DFR0_BRPS_SHIFT);
 }
 
 /* Determine number of WRP registers available. */
 static inline int get_num_wrps(void)
 {
-	return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
+	return 1 +
+		cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
+						ID_AA64DFR0_WRPS_SHIFT);
 }
 
 #endif	/* __KERNEL__ */
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index cebf786..c0a2327 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -26,14 +26,16 @@ 
 #include <linux/stat.h>
 #include <linux/uaccess.h>
 
-#include <asm/debug-monitors.h>
+#include <asm/cpufeature.h>
 #include <asm/cputype.h>
+#include <asm/debug-monitors.h>
 #include <asm/system_misc.h>
 
 /* Determine debug architecture. */
 u8 debug_monitors_arch(void)
 {
-	return read_cpuid(ID_AA64DFR0_EL1) & 0xf;
+	return cpuid_feature_extract_field(read_system_reg(SYS_ID_AA64DFR0_EL1),
+						ID_AA64DFR0_DEBUGVER_SHIFT);
 }
 
 /*