All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org
Cc: mathieu.poirier@linaro.org, mike.leach@linaro.org,
	Linu Cherian <lcherian@marvell.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 10/11] coresight: sink: Add TRBE driver
Date: Sun, 17 Jan 2021 17:40:23 +0530	[thread overview]
Message-ID: <2fb48d88-f195-ca48-5d87-f402ac4e4381@arm.com> (raw)
In-Reply-To: <f6262d21-c72e-3b7e-59a1-8f14441d809d@arm.com>



On 1/15/21 6:13 PM, Suzuki K Poulose wrote:
> On 1/15/21 5:29 AM, Anshuman Khandual wrote:
>>
>>
>> On 1/13/21 8:58 PM, Suzuki K Poulose wrote:
>>> Hi Anshuman,
>>>
>>> The driver looks overall good to me. Please find some minor comments below

Sure.

>>>
>>> On 1/13/21 4:18 AM, Anshuman Khandual wrote:
>>>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>>>> accessible via the system registers. The TRBE supports different addressing
>>>> modes including CPU virtual address and buffer modes including the circular
>>>> buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
>>>> an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
>>>> access to the trace buffer could be prohibited by a higher exception level
>>>> (EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
>>>> private interrupt (PPI) on address translation errors and when the buffer
>>>> is full. Overall implementation here is inspired from the Arm SPE driver.
>>>>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Mike Leach <mike.leach@linaro.org>
>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> 
> ...
> 
>>>> +
>>>> +/*
>>>> + * TRBE Buffer Management
>>>> + *
>>>> + * The TRBE buffer spans from the base pointer till the limit pointer. When enabled,
>>>> + * it starts writing trace data from the write pointer onward till the limit pointer.
>>>
>>>
>>>> + * When the write pointer reaches the address just before the limit pointer, it gets
>>>> + * wrapped around again to the base pointer. This is called a TRBE wrap event, which
>>>> + * generates a maintenance interrupt when operated in WRAP or STOP mode.
>>>
>>> According to the TRM, it is FILL mode, instead of STOP. So please change the above to:
>>>
>>> "operated in WRAP or FILL mode".

Changed.

>>
>> Updated.
>>
>>>
>>>
>>>>      The write
>>>> + * pointer again starts writing trace data from the base pointer until just before
>>>> + * the limit pointer before getting wrapped again with an IRQ and this process just
>>>> + * goes on as long as the TRBE is enabled.
>>>
>>> This could be dropped as it applies to WRAP/CIRCULAR buffer mode, which we don't use.
>>
>> Probably this could be changed a bit to match the FILL mode. Because it is essential
>> to describe the continuous nature of the buffer operation, even in the FILL mode.
>>
>>   * After TRBE
>>   * IRQ gets handled and enabled again, write pointer again starts writing trace data
>>   * from the base pointer until just before the limit pointer before getting wrapped
>>   * again with an IRQ and this process just goes on as long as the TRBE is enabled.
>>
> 
> The above doesn't parse well and kind of repeats the operation of TRBE which is
> already explained above. How about :
> 
>>>> + * When the write pointer reaches the address just before the limit pointer, it gets
>>>> + * wrapped around again to the base pointer. This is called a TRBE wrap event, which
>>>> + * generates a maintenance interrupt when operated in WRAP or STOP mode.
> 
> This driver uses FILL mode, where the TRBE stops the trace collection at wrap event.
> The IRQ handler updates the AUX buffer and re-enables the TRBE with updated WRITE and
> LIMIT pointers.

Updated.

> 
> 
>>>> +
>>>> +static void *arm_trbe_alloc_buffer(struct coresight_device *csdev,
>>>> +                   struct perf_event *event, void **pages,
>>>> +                   int nr_pages, bool snapshot)
>>>> +{
>>>> +    struct trbe_buf *buf;
>>>> +    struct page **pglist;
>>>> +    int i;
>>>> +
>>>> +    if ((nr_pages < 2) || (snapshot && (nr_pages & 1)))
>>>
>>> This restriction on snapshot could be removed now, since we use the
>>> full buffer.
>>
>> Dropped only the second condition here i.e (snapshot && (nr_pages & 1).
>> Just wondering if the aux buffer could work with a single page so that
>> the first condition can also be dropped.
> 
> I think it is good to keep the restriction of 2 pages, as the WRITE_PTR
> and the LIMIT_PTR must be page aligned. With a single page, you can't do
> much, with writing into a partially filled buffer. This may be added
> as a comment to explain the restriction.

Added the above comment.

> 
>>>> +
>>>> +static enum trbe_fault_action trbe_get_fault_act(struct perf_output_handle *handle)
>>>> +{
>>>> +    int ec = get_trbe_ec();
>>>> +    int bsc = get_trbe_bsc();
>>>> +
>>>> +    WARN_ON(is_trbe_running());
>>>> +    if (is_trbe_trg() || is_trbe_abort())
>>>
>>> We seem to be reading the TRBSR every single in these helpers. Could we optimise them
>>> by passing the register value in ?
>>
>> The same goes for get_trbe_ec() and get_trbe_bsc() as well. Probably all
>> TRBSR field probing helpers should be modified to accept a TRBSR register
>> value instead.
>>
>>>
>>> i.e
>>>      u64 trbsr = get_trbe_status();
>>>
>>>      WARN_ON(is_trbe_runnign(trbsr))
>>>      if (is_trbe_trg(trbsr) || is_trbe_abort(trbsr))
>>>
>>> For is_trbe_wrap() too
>>
>> Yes.
>>
>>>
> 
> 
>>>
>>> We should skip the driver init, if the kernel is unmapped at EL0,
>>> as the TRBE can't safely write to the kernel virtual addressed
>>> buffer when the CPU is running at EL0. This is unlikely, but we
>>> should cover that case.
>>
>> This should be sufficient or it needs a pr_err() as well ?
>>
> 
> Please add a pr_err() message to indicate why this failed. Otherwise
> the user could be left with no clue.

Sure, will add the following before exiting the TRBE init.

pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n")

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org
Cc: linux-kernel@vger.kernel.org, Linu Cherian <lcherian@marvell.com>,
	mathieu.poirier@linaro.org, mike.leach@linaro.org
Subject: Re: [PATCH V2 10/11] coresight: sink: Add TRBE driver
Date: Sun, 17 Jan 2021 17:40:23 +0530	[thread overview]
Message-ID: <2fb48d88-f195-ca48-5d87-f402ac4e4381@arm.com> (raw)
In-Reply-To: <f6262d21-c72e-3b7e-59a1-8f14441d809d@arm.com>



On 1/15/21 6:13 PM, Suzuki K Poulose wrote:
> On 1/15/21 5:29 AM, Anshuman Khandual wrote:
>>
>>
>> On 1/13/21 8:58 PM, Suzuki K Poulose wrote:
>>> Hi Anshuman,
>>>
>>> The driver looks overall good to me. Please find some minor comments below

Sure.

>>>
>>> On 1/13/21 4:18 AM, Anshuman Khandual wrote:
>>>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>>>> accessible via the system registers. The TRBE supports different addressing
>>>> modes including CPU virtual address and buffer modes including the circular
>>>> buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
>>>> an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
>>>> access to the trace buffer could be prohibited by a higher exception level
>>>> (EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
>>>> private interrupt (PPI) on address translation errors and when the buffer
>>>> is full. Overall implementation here is inspired from the Arm SPE driver.
>>>>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Mike Leach <mike.leach@linaro.org>
>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> 
> ...
> 
>>>> +
>>>> +/*
>>>> + * TRBE Buffer Management
>>>> + *
>>>> + * The TRBE buffer spans from the base pointer till the limit pointer. When enabled,
>>>> + * it starts writing trace data from the write pointer onward till the limit pointer.
>>>
>>>
>>>> + * When the write pointer reaches the address just before the limit pointer, it gets
>>>> + * wrapped around again to the base pointer. This is called a TRBE wrap event, which
>>>> + * generates a maintenance interrupt when operated in WRAP or STOP mode.
>>>
>>> According to the TRM, it is FILL mode, instead of STOP. So please change the above to:
>>>
>>> "operated in WRAP or FILL mode".

Changed.

>>
>> Updated.
>>
>>>
>>>
>>>>      The write
>>>> + * pointer again starts writing trace data from the base pointer until just before
>>>> + * the limit pointer before getting wrapped again with an IRQ and this process just
>>>> + * goes on as long as the TRBE is enabled.
>>>
>>> This could be dropped as it applies to WRAP/CIRCULAR buffer mode, which we don't use.
>>
>> Probably this could be changed a bit to match the FILL mode. Because it is essential
>> to describe the continuous nature of the buffer operation, even in the FILL mode.
>>
>>   * After TRBE
>>   * IRQ gets handled and enabled again, write pointer again starts writing trace data
>>   * from the base pointer until just before the limit pointer before getting wrapped
>>   * again with an IRQ and this process just goes on as long as the TRBE is enabled.
>>
> 
> The above doesn't parse well and kind of repeats the operation of TRBE which is
> already explained above. How about :
> 
>>>> + * When the write pointer reaches the address just before the limit pointer, it gets
>>>> + * wrapped around again to the base pointer. This is called a TRBE wrap event, which
>>>> + * generates a maintenance interrupt when operated in WRAP or STOP mode.
> 
> This driver uses FILL mode, where the TRBE stops the trace collection at wrap event.
> The IRQ handler updates the AUX buffer and re-enables the TRBE with updated WRITE and
> LIMIT pointers.

Updated.

> 
> 
>>>> +
>>>> +static void *arm_trbe_alloc_buffer(struct coresight_device *csdev,
>>>> +                   struct perf_event *event, void **pages,
>>>> +                   int nr_pages, bool snapshot)
>>>> +{
>>>> +    struct trbe_buf *buf;
>>>> +    struct page **pglist;
>>>> +    int i;
>>>> +
>>>> +    if ((nr_pages < 2) || (snapshot && (nr_pages & 1)))
>>>
>>> This restriction on snapshot could be removed now, since we use the
>>> full buffer.
>>
>> Dropped only the second condition here i.e (snapshot && (nr_pages & 1).
>> Just wondering if the aux buffer could work with a single page so that
>> the first condition can also be dropped.
> 
> I think it is good to keep the restriction of 2 pages, as the WRITE_PTR
> and the LIMIT_PTR must be page aligned. With a single page, you can't do
> much, with writing into a partially filled buffer. This may be added
> as a comment to explain the restriction.

Added the above comment.

> 
>>>> +
>>>> +static enum trbe_fault_action trbe_get_fault_act(struct perf_output_handle *handle)
>>>> +{
>>>> +    int ec = get_trbe_ec();
>>>> +    int bsc = get_trbe_bsc();
>>>> +
>>>> +    WARN_ON(is_trbe_running());
>>>> +    if (is_trbe_trg() || is_trbe_abort())
>>>
>>> We seem to be reading the TRBSR every single in these helpers. Could we optimise them
>>> by passing the register value in ?
>>
>> The same goes for get_trbe_ec() and get_trbe_bsc() as well. Probably all
>> TRBSR field probing helpers should be modified to accept a TRBSR register
>> value instead.
>>
>>>
>>> i.e
>>>      u64 trbsr = get_trbe_status();
>>>
>>>      WARN_ON(is_trbe_runnign(trbsr))
>>>      if (is_trbe_trg(trbsr) || is_trbe_abort(trbsr))
>>>
>>> For is_trbe_wrap() too
>>
>> Yes.
>>
>>>
> 
> 
>>>
>>> We should skip the driver init, if the kernel is unmapped at EL0,
>>> as the TRBE can't safely write to the kernel virtual addressed
>>> buffer when the CPU is running at EL0. This is unlikely, but we
>>> should cover that case.
>>
>> This should be sufficient or it needs a pr_err() as well ?
>>
> 
> Please add a pr_err() message to indicate why this failed. Otherwise
> the user could be left with no clue.

Sure, will add the following before exiting the TRBE init.

pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n")

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

  reply	other threads:[~2021-01-17 12:11 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13  4:18 [PATCH V2 00/11] arm64: coresight: Enable ETE and TRBE Anshuman Khandual
2021-01-13  4:18 ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 01/11] coresight: etm-perf: Allow an event to use different sinks Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 02/11] coresight: Do not scan for graph if none is present Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 03/11] coresight: etm4x: Add support for PE OS lock Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 04/11] coresight: ete: Add support for ETE sysreg access Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 05/11] coresight: ete: Add support for ETE tracing Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 06/11] dts: bindings: Document device tree bindings for ETE Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-25 19:22   ` Rob Herring
2021-01-25 19:22     ` Rob Herring
2021-01-25 22:20     ` Suzuki K Poulose
2021-01-25 22:20       ` Suzuki K Poulose
2021-01-25 23:28       ` Suzuki K Poulose
2021-01-25 23:28         ` Suzuki K Poulose
2021-01-13  4:18 ` [PATCH V2 07/11] arm64: Add TRBE definitions Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  9:21   ` Suzuki K Poulose
2021-01-13  9:21     ` Suzuki K Poulose
2021-01-15  1:52     ` Anshuman Khandual
2021-01-15  1:52       ` Anshuman Khandual
2021-02-22 13:55   ` Catalin Marinas
2021-02-22 13:55     ` Catalin Marinas
2021-02-22 13:59     ` Catalin Marinas
2021-02-22 13:59       ` Catalin Marinas
2021-01-13  4:18 ` [PATCH V2 08/11] coresight: core: Add support for dedicated percpu sinks Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  9:43   ` Suzuki K Poulose
2021-01-13  9:43     ` Suzuki K Poulose
2021-01-15  2:36     ` Anshuman Khandual
2021-01-15  2:36       ` Anshuman Khandual
2021-01-15 12:31       ` Suzuki K Poulose
2021-01-15 12:31         ` Suzuki K Poulose
2021-01-13  4:18 ` [PATCH V2 09/11] coresight: etm-perf: Truncate the perf record if handle has no space Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13  9:48   ` Suzuki K Poulose
2021-01-13  9:48     ` Suzuki K Poulose
2021-01-13  4:18 ` [PATCH V2 10/11] coresight: sink: Add TRBE driver Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13 15:28   ` Suzuki K Poulose
2021-01-13 15:28     ` Suzuki K Poulose
2021-01-15  5:29     ` Anshuman Khandual
2021-01-15  5:29       ` Anshuman Khandual
2021-01-15 12:43       ` Suzuki K Poulose
2021-01-15 12:43         ` Suzuki K Poulose
2021-01-17 12:10         ` Anshuman Khandual [this message]
2021-01-17 12:10           ` Anshuman Khandual
2021-01-13  4:18 ` [PATCH V2 11/11] dts: bindings: Document device tree bindings for Arm TRBE Anshuman Khandual
2021-01-13  4:18   ` Anshuman Khandual
2021-01-13 15:45   ` Rob Herring
2021-01-13 15:45     ` Rob Herring
2021-01-14 10:17     ` Suzuki K Poulose
2021-01-14 10:17       ` Suzuki K Poulose
2021-01-14 14:07   ` Rob Herring
2021-01-14 14:07     ` Rob Herring
2021-01-14 14:47     ` Suzuki K Poulose
2021-01-14 14:47       ` Suzuki K Poulose

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=2fb48d88-f195-ca48-5d87-f402ac4e4381@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=lcherian@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=suzuki.poulose@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.