Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1242206 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 16/22] arm64/debug: Make use of the system wide safe  value Catalin Marinas <catalin.marinas@arm.com> - 2015-10-08 13:20 +0200
    Re: [PATCH v2 16/22] arm64/debug: Make use of the system wide safe  value "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-08 14:00 +0200
      Re: [PATCH v2 16/22] arm64/debug: Make use of the system wide safe  value Catalin Marinas <catalin.marinas@arm.com> - 2015-10-08 17:10 +0200
        Re: [PATCH v2 16/22] arm64/debug: Make use of the system wide safe  value "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-08 18:00 +0200

#1242206 — Re: [PATCH v2 16/22] arm64/debug: Make use of the system wide safe value

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.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1242280

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242497

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().

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242557

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web