linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Zhou <jonathan.zhouwen@huawei.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<mathieu.poirier@linaro.org>
Cc: zhangshaokun@hisilicon.com, catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH v2] Coresight: etm4x: add support for Self-hosted trace
Date: Tue, 15 Sep 2020 22:43:04 +0800	[thread overview]
Message-ID: <ff125cd4-0c23-654c-6217-c9abad17ed85@huawei.com> (raw)
In-Reply-To: <95aaa024-7462-9f33-1df7-896da7eb6565@arm.com>

On 09/09/2020 17:05, Suzuki K Poulose wrote:
> On 09/09/2020 08:56 AM, Jonathan Zhou wrote:
>> Hi Suzuki
>>
>> Thanks for your review.
>>
>> On 08/09/2020 17:56, Suzuki K Poulose wrote:
>>> On 08/31/2020 09:02 AM, Jonathan Zhou wrote:
>>>> ARMv8.4 architecture extension introduces ARMv8.4-Trace, Armv8.4
>>>> Self-hosted Trace Extensions. It provides control of exception
>>>> levels and security states. Let's add this feature detection and
>>>> enable E1TRE and E0TRE in TRFCR_EL1 if Self-hosted Trace is
>>>> supported.
>>>>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
>>>> Signed-off-by: Jonathan Zhou <jonathan.zhouwen@huawei.com>
>>>> ---
>>>>    arch/arm64/include/asm/sysreg.h               |  8 ++++++++
>>>>    drivers/hwtracing/coresight/coresight-etm4x.c | 23
>>>> +++++++++++++++++++++++
>>>>    2 files changed, 31 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/include/asm/sysreg.h
>>>> b/arch/arm64/include/asm/sysreg.h
>>>> index 554a7e8ecb07..53da5f326667 100644
>>>> --- a/arch/arm64/include/asm/sysreg.h
>>>> +++ b/arch/arm64/include/asm/sysreg.h
>>>> @@ -184,6 +184,13 @@
>>>>      #define SYS_ZCR_EL1            sys_reg(3, 0, 1, 2, 0)
>>>>    +/* Trace Filter control */
>>>> +#define SYS_TRFCR_EL1            sys_reg(3, 0, 1, 2, 1)
>>>
>>>> +/* Trace is allowed at EL0 */
>>>> +#define SYS_TRFCR_EL1_E0TRE        BIT(0)
>>>> +/* Trace is allowed at EL1 */
>>>> +#define SYS_TRFCR_EL1_E1TRE        BIT(1)
>>>> +
>>>
>>> Please drop SYS suffix for the fields.
>>>
>> Thanks, I will fix this.
>>
>>>>    #define SYS_TTBR0_EL1            sys_reg(3, 0, 2, 0, 0)
>>>>    #define SYS_TTBR1_EL1            sys_reg(3, 0, 2, 0, 1)
>>>>    #define SYS_TCR_EL1            sys_reg(3, 0, 2, 0, 2)
>>>> @@ -772,6 +779,7 @@
>>>>    #define ID_AA64MMFR2_CNP_SHIFT        0
>>>>      /* id_aa64dfr0 */
>>>> +#define ID_AA64DFR0_SELF_HOSTED_SHIFT    40
>>>>    #define ID_AA64DFR0_DOUBLELOCK_SHIFT    36
>>>>    #define ID_AA64DFR0_PMSVER_SHIFT    32
>>>>    #define ID_AA64DFR0_CTX_CMPS_SHIFT    28
>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
>>>> b/drivers/hwtracing/coresight/coresight-etm4x.c
>>>> index 96425e818fc2..f72b457c2bad 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
>>>> @@ -28,6 +28,7 @@
>>>>    #include <linux/perf_event.h>
>>>>    #include <linux/pm_runtime.h>
>>>>    #include <linux/property.h>
>>>> +#include <asm/sysreg.h>
>>>>    #include <asm/sections.h>
>>>>    #include <asm/local.h>
>>>>    #include <asm/virt.h>
>>>> @@ -785,6 +786,24 @@ static void etm4_init_arch_data(void *info)
>>>>        CS_LOCK(drvdata->base);
>>>>    }
>>>>    +static void etm4_init_sysctrl(void *info)
>>>> +{
>>>> +    u64 sys_trfcr_el1, dfr0;
>>>> +    int trace_filt;
>>>> +
>>>> +    dfr0 = read_sysreg(id_aa64dfr0_el1);
>>>> +
>>>> +    trace_filt = cpuid_feature_extract_unsigned_field(dfr0,
>>>> +                    ID_AA64DFR0_SELF_HOSTED_SHIFT);
>>>> +    /* if selfhosted trace implemented, enable trace EL0 as
>>>> default. */
>>>
>>> What about EL1 ? We do support kernel tracing. I believe we need to do
>>> this every time when we enable etm4, based on the selected config.
>>>
>> I don't know if it's possible to run trace sessions in a guest OS, so I
>> left the EL1 and EL2 trace disabled. And it's right. We need to provide
>> an interface to select these configs include the CX and TS feilds of
>> TRFCR_EL2. How about a sysfs interface?
> 
> No, you don't need any additional interfaces. The etm4_config should
> tell us, if the ETM4 is supposed to filter events for kernel/userspace.
> We don't have virtualization support yet, so we could ignore the
> TRFCR_EL2, for now.
> 

Thanks, virtualization is really something out of my mind.

> Either we :
> 
> 1) Unconditionally enable EL1 & EL0 tracing on each ETMv4 instance
> at probe time and leave the trace exclusion by EL to deal with the
> kernel/userspace filtering.
> 
> OR
> 
> 2) For each session of ETMv4 tracing, program the EL1 and EL0 trace
> in TRFCR_EL1 based on the exclusion requested by ELs in the configs.
> 
> I prefer (1). Also, we must enable CX for TRFCR_EL2, if we are in VHE
> to allow contextid tracing.
> 
Yes, (1) seems to be better. Programming TRFCR_ELx based on the ETM
viewinst ELs' configs looks a little strange, for they are filters on
different level. I will apply this in PATCH V3.

Regards.
Jonathan

> TS could be set to 0b01 in either case, to use the virtual timestamp.
> 
> Suzuki
> 
> 
> 
> 
> 
>>
>> Regards.
>> Jonathan.
>>>
>>> Suzuki
>>> .
>>
> 
> .


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2020-09-15 14:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31  8:02 [PATCH v2] Coresight: etm4x: add support for Self-hosted trace Jonathan Zhou
2020-09-07 21:00 ` Will Deacon
2020-09-09  6:38   ` Jonathan Zhou
2020-09-08  9:56 ` Suzuki K Poulose
2020-09-09  7:56   ` Jonathan Zhou
2020-09-09  9:05     ` Suzuki K Poulose
2020-09-15 14:43       ` Jonathan Zhou [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ff125cd4-0c23-654c-6217-c9abad17ed85@huawei.com \
    --to=jonathan.zhouwen@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=zhangshaokun@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).