linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe
@ 2022-02-01 12:22 Sudeep Holla
  2022-02-03  6:25 ` Anshuman Khandual
  0 siblings, 1 reply; 5+ messages in thread
From: Sudeep Holla @ 2022-02-01 12:22 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: Sudeep Holla, Mathieu Poirier, Suzuki K Poulose, Mike Leach,
	Leo Yan, Anshuman Khandual, coresight

Currently with the check present in the module initialisation, it shouts
on all the systems irrespective of presence of coresight trace buffer
extensions.

Similar to Arm SPE perf driver, move the check for kernelspace unmapping
when running at EL0 to the device probe instead of module initialisation.

Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: coresight@lists.linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/hwtracing/coresight/coresight-trbe.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 276862c07e32..3fe2ce1ba5bf 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -1423,6 +1423,11 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	int ret;
 
+	if (arm64_kernel_unmapped_at_el0()) {
+		pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n");
+		return -EOPNOTSUPP;
+	}
+
 	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
 	if (!drvdata)
 		return -ENOMEM;
@@ -1484,11 +1489,6 @@ static int __init arm_trbe_init(void)
 {
 	int ret;
 
-	if (arm64_kernel_unmapped_at_el0()) {
-		pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n");
-		return -EOPNOTSUPP;
-	}
-
 	ret = platform_driver_register(&arm_trbe_driver);
 	if (!ret)
 		return 0;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe
  2022-02-01 12:22 [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe Sudeep Holla
@ 2022-02-03  6:25 ` Anshuman Khandual
  2022-02-03 12:04   ` Sudeep Holla
  0 siblings, 1 reply; 5+ messages in thread
From: Anshuman Khandual @ 2022-02-03  6:25 UTC (permalink / raw)
  To: Sudeep Holla, linux-arm-kernel, linux-kernel
  Cc: Mathieu Poirier, Suzuki K Poulose, Mike Leach, Leo Yan, coresight



On 2/1/22 5:52 PM, Sudeep Holla wrote:
> Currently with the check present in the module initialisation, it shouts
> on all the systems irrespective of presence of coresight trace buffer
> extensions.

IIUC a system with CONFIG_CORESIGHT_TRBE enabled but without a TRBE DT
i.e "arm,trace-buffer-extension" complains about kernel space unmapping
at EL0 (even though it does not even really have TRBE HW to initialize).

> 
> Similar to Arm SPE perf driver, move the check for kernelspace unmapping
> when running at EL0 to the device probe instead of module initialisation.

Makes sense.

> 
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Mike Leach <mike.leach@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: coresight@lists.linaro.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/hwtracing/coresight/coresight-trbe.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 276862c07e32..3fe2ce1ba5bf 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -1423,6 +1423,11 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	int ret;
>  

Could you please add a similar comment like SPE driver regarding how
the TRBE buffer will be inaccessible, if kernel gets unmapped at EL0
and trace capture will terminate.

> +	if (arm64_kernel_unmapped_at_el0()) {
> +		pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n");
> +		return -EOPNOTSUPP;
> +	}
> +
>  	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>  	if (!drvdata)
>  		return -ENOMEM;
> @@ -1484,11 +1489,6 @@ static int __init arm_trbe_init(void)
>  {
>  	int ret;
>  
> -	if (arm64_kernel_unmapped_at_el0()) {
> -		pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n");
> -		return -EOPNOTSUPP;
> -	}
> -
>  	ret = platform_driver_register(&arm_trbe_driver);
>  	if (!ret)
>  		return 0;
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe
  2022-02-03  6:25 ` Anshuman Khandual
@ 2022-02-03 12:04   ` Sudeep Holla
  2022-02-03 12:17     ` Anshuman Khandual
  2022-02-03 12:21     ` Suzuki K Poulose
  0 siblings, 2 replies; 5+ messages in thread
From: Sudeep Holla @ 2022-02-03 12:04 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: linux-arm-kernel, linux-kernel, Mathieu Poirier,
	Suzuki K Poulose, Mike Leach, Leo Yan, coresight

On Thu, Feb 03, 2022 at 11:55:58AM +0530, Anshuman Khandual wrote:
> 
> 
> On 2/1/22 5:52 PM, Sudeep Holla wrote:
> > Currently with the check present in the module initialisation, it shouts
> > on all the systems irrespective of presence of coresight trace buffer
> > extensions.
> 
> IIUC a system with CONFIG_CORESIGHT_TRBE enabled but without a TRBE DT
> i.e "arm,trace-buffer-extension" complains about kernel space unmapping
> at EL0 (even though it does not even really have TRBE HW to initialize).


Correct. Basically, this error will be seen on all systems(DT and ACPI) when
the module is compiled. It really doesn't matter if the system supports TRBE.

> > 
> > Similar to Arm SPE perf driver, move the check for kernelspace unmapping
> > when running at EL0 to the device probe instead of module initialisation.
> 
> Makes sense.
>

Thanks.

> > 
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Mike Leach <mike.leach@linaro.org>
> > Cc: Leo Yan <leo.yan@linaro.org>
> > Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> > Cc: coresight@lists.linaro.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/hwtracing/coresight/coresight-trbe.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> > index 276862c07e32..3fe2ce1ba5bf 100644
> > --- a/drivers/hwtracing/coresight/coresight-trbe.c
> > +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> > @@ -1423,6 +1423,11 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	int ret;
> >  
> 
> Could you please add a similar comment like SPE driver regarding how
> the TRBE buffer will be inaccessible, if kernel gets unmapped at EL0
> and trace capture will terminate.
>

Sure I can add that. But if the device probe fails, will you be able to even
start the trace capture, sorry I didn't get what you mean by "trace capture
will terminate". I assume it must be "trace capture is not possible or not
allowed" IIUC.

-- 
Regards,
Sudeep

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe
  2022-02-03 12:04   ` Sudeep Holla
@ 2022-02-03 12:17     ` Anshuman Khandual
  2022-02-03 12:21     ` Suzuki K Poulose
  1 sibling, 0 replies; 5+ messages in thread
From: Anshuman Khandual @ 2022-02-03 12:17 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: linux-arm-kernel, linux-kernel, Mathieu Poirier,
	Suzuki K Poulose, Mike Leach, Leo Yan, coresight



On 2/3/22 5:34 PM, Sudeep Holla wrote:
>> Could you please add a similar comment like SPE driver regarding how
>> the TRBE buffer will be inaccessible, if kernel gets unmapped at EL0
>> and trace capture will terminate.
>>
> Sure I can add that. But if the device probe fails, will you be able to even
> start the trace capture, sorry I didn't get what you mean by "trace capture
> will terminate". I assume it must be "trace capture is not possible or not
> allowed" IIUC.

I guess the comment should be framed like - what might happen if the following
code block which checks for arm64_kernel_unmapped_at_el0() is not present. If
TRBE gets enabled along with kernel unmapping at EL0 supported, trace capture
will terminate.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe
  2022-02-03 12:04   ` Sudeep Holla
  2022-02-03 12:17     ` Anshuman Khandual
@ 2022-02-03 12:21     ` Suzuki K Poulose
  1 sibling, 0 replies; 5+ messages in thread
From: Suzuki K Poulose @ 2022-02-03 12:21 UTC (permalink / raw)
  To: Sudeep Holla, Anshuman Khandual
  Cc: linux-arm-kernel, linux-kernel, Mathieu Poirier, Mike Leach,
	Leo Yan, coresight

On 03/02/2022 12:04, Sudeep Holla wrote:
> On Thu, Feb 03, 2022 at 11:55:58AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 2/1/22 5:52 PM, Sudeep Holla wrote:
>>> Currently with the check present in the module initialisation, it shouts
>>> on all the systems irrespective of presence of coresight trace buffer
>>> extensions.
>>
>> IIUC a system with CONFIG_CORESIGHT_TRBE enabled but without a TRBE DT
>> i.e "arm,trace-buffer-extension" complains about kernel space unmapping
>> at EL0 (even though it does not even really have TRBE HW to initialize).
> 
> 
> Correct. Basically, this error will be seen on all systems(DT and ACPI) when
> the module is compiled. It really doesn't matter if the system supports TRBE.
> 
>>>
>>> Similar to Arm SPE perf driver, move the check for kernelspace unmapping
>>> when running at EL0 to the device probe instead of module initialisation.
>>
>> Makes sense.
>>
> 
> Thanks.
> 
>>>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> Cc: Mike Leach <mike.leach@linaro.org>
>>> Cc: Leo Yan <leo.yan@linaro.org>
>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>> Cc: coresight@lists.linaro.org
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>   drivers/hwtracing/coresight/coresight-trbe.c | 10 +++++-----
>>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>>> index 276862c07e32..3fe2ce1ba5bf 100644
>>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>>> @@ -1423,6 +1423,11 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
>>>   	struct device *dev = &pdev->dev;
>>>   	int ret;
>>>   
>>
>> Could you please add a similar comment like SPE driver regarding how
>> the TRBE buffer will be inaccessible, if kernel gets unmapped at EL0
>> and trace capture will terminate.
>>
> 
> Sure I can add that. But if the device probe fails, will you be able to even
> start the trace capture, sorry I didn't get what you mean by "trace capture
> will terminate". I assume it must be "trace capture is not possible or not
> allowed" IIUC.
> 

"Trace capture is not possible with kernel page table isolation"

  is good enough.

Thanks for making these changes

Cheers
Suzuki


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-02-03 12:21 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01 12:22 [PATCH] coresight: trbe: Move check for kernelspace unmapped at EL0 to probe Sudeep Holla
2022-02-03  6:25 ` Anshuman Khandual
2022-02-03 12:04   ` Sudeep Holla
2022-02-03 12:17     ` Anshuman Khandual
2022-02-03 12:21     ` Suzuki K Poulose

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).