From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:01
This series enables future IP trace features Embedded Trace Extension
(ETE) and Trace Buffer Extension (TRBE). This series applies on
v5.12-rc4 + some patches queued. A standalone tree is also available here [0].
The queued patches (almost there) are included in this posting for
the sake of constructing a tree from the posting.
ETE is the PE (CPU) trace unit for CPUs, implementing future
architecture extensions. ETE overlaps with the ETMv4 architecture, with
additions to support the newer architecture features and some restrictions
on the supported features w.r.t ETMv4. The ETE support is added by extending
the ETMv4 driver to recognise the ETE and handle the features as exposed by
the TRCIDRx registers. ETE only supports system instructions access from the
host CPU. The ETE could be integrated with a TRBE (see below), or with
the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same
firmware description as the ETMs and requires a node per instance.
Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which
is accessible via the system registers and can be combined with the ETE to
provide a 1x1 configuration of source & sink. TRBE is being represented
here as a CoreSight sink. Primary reason is that the ETE source could
work with other traditional CoreSight sink devices. As TRBE captures the
trace data which is produced by ETE, it cannot work alone.
TRBE representation here have some distinct deviations from a
traditional CoreSight sink device. Coresight path between ETE and TRBE are
not built during boot looking at respective DT or ACPI entries.
Unlike traditional sinks, TRBE can generate interrupts to signal
including many other things, buffer got filled. The interrupt is a PPI and
should be communicated from the platform. DT or ACPI entry representing TRBE
should have the PPI number for a given platform. During perf session, the
TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting
it back. System registers being used here to configure ETE and TRBE could
be referred in the link below.
https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers.
[0] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/ete/v5/
Changes since V4:
https://lkml.kernel.org/r/20210225193543.2920532-1-suzuki.poulose@arm.com
- Split the documentation patches from the TRBE driver
- Drop the patches already queued for v5.12.
- Mark the buffer TRUNCATED in case of a WRAP event
- Fix error code for vmap failure
- Fix build break on arm32 for per-cpu sink patch
- Address comments on ETE dts bindings.
- Make ete_sysreg_read/write static (kernel test robot)
- Merged ete sysreg definition patch with ete support, to avoid
a "defined but unused warning" on build in part of the series.
- Add new bindings to MAINTAINERS
Changes since V3:
https://lore.kernel.org/linux-arm-kernel/1611737738-1493-1-git-send-email-anshuman.khandual@arm.com/
- ETE and TRBE changes have been captured in the respective patches
- Better support for nVHE
- Re-ordered and splitted the patches to keep the changes separate
for the generic/arm64 tree from CoreSight driver specific changes.
- Fixes for KVM handling of Trace/SPE
Changes since V2:
https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-anshuman.khandual@arm.com/
- Rebased on coresight/next
- Changed DT bindings for ETE
- Included additional patches for arm64 nvhe, perf aux buffer flags etc
- TRBE changes have been captured in the respective patches
Changes since V1:
https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-anshuman.khandual@arm.com/
- Converted both ETE and TRBE DT bindings into Yaml
- TRBE changes have been captured in the respective patches
Changes since RFC:
- There are not much ETE changes from Suzuki apart from splitting of the
ETE DTS patch
- TRBE changes have been captured in the respective patches
RFC:
https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-anshuman.khandual@arm.com/
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Zilstra <peterz@infradead.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Linu Cherian <redacted>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Anshuman Khandual (5):
arm64: Add TRBE definitions
coresight: core: Add support for dedicated percpu sinks
coresight: sink: Add TRBE driver
Documentation: coresight: trbe: Sysfs ABI description
Documentation: trace: Add documentation for TRBE
Suzuki K Poulose (14):
[Queued] kvm: arm64: Hide system instruction access to Trace registers
[Queued] kvm: arm64: Disable guest access to trace filter controls
perf: aux: Add flags for the buffer format
perf: aux: Add CoreSight PMU buffer formats
arm64: Add support for trace synchronization barrier
arm64: kvm: Enable access to TRBE support for host
coresight: etm4x: Move ETM to prohibited region for disable
coresight: etm-perf: Allow an event to use different sinks
coresight: Do not scan for graph if none is present
coresight: etm4x: Add support for PE OS lock
coresight: ete: Add support for ETE tracing
dts: bindings: Document device tree bindings for ETE
coresight: etm-perf: Handle stale output handles
dts: bindings: Document device tree bindings for Arm TRBE
.../testing/sysfs-bus-coresight-devices-trbe | 14 +
.../devicetree/bindings/arm/ete.yaml | 75 ++
.../devicetree/bindings/arm/trbe.yaml | 49 +
.../trace/coresight/coresight-trbe.rst | 38 +
MAINTAINERS | 2 +
arch/arm64/include/asm/barrier.h | 1 +
arch/arm64/include/asm/el2_setup.h | 13 +
arch/arm64/include/asm/kvm_arm.h | 3 +
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/include/asm/sysreg.h | 50 +
arch/arm64/kernel/cpufeature.c | 1 -
arch/arm64/kernel/hyp-stub.S | 3 +-
arch/arm64/kvm/debug.c | 6 +-
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 +
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
drivers/hwtracing/coresight/Kconfig | 24 +-
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-core.c | 29 +-
.../hwtracing/coresight/coresight-etm-perf.c | 119 +-
.../coresight/coresight-etm4x-core.c | 161 ++-
.../coresight/coresight-etm4x-sysfs.c | 19 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 83 +-
.../hwtracing/coresight/coresight-platform.c | 6 +
drivers/hwtracing/coresight/coresight-priv.h | 3 +
drivers/hwtracing/coresight/coresight-trbe.c | 1157 +++++++++++++++++
drivers/hwtracing/coresight/coresight-trbe.h | 152 +++
include/linux/coresight.h | 13 +
include/uapi/linux/perf_event.h | 13 +-
28 files changed, 2016 insertions(+), 64 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:03
Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.
Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
--
Note: Marc has indicated that he will be picking this patch
I have included in the series for ease of testing.
---
arch/arm64/kernel/cpufeature.c | 1 -
1 file changed, 1 deletion(-)
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:03
Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.
This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Note: Marc has indicated that this will be queued for 5.12.
I have included this in the series for the sake of constructing
a full tree from the posting
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/debug.c | 2 ++
2 files changed, 3 insertions(+)
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:03
Allocate a byte for advertising the PMU specific format type
of the given AUX record. A PMU could end up providing hardware
trace data in multiple format in a single session.
e.g, The format of hardware buffer produced by CoreSight ETM
PMU depends on the type of the "sink" device used for collection
for an event (Traditional TMC-ETR/Bs with formatting or
TRBEs without any formatting).
# Boring story of why this is needed. Goto The_End_of_Story for skipping.
CoreSight ETM trace allows instruction level tracing of Arm CPUs.
The ETM generates the CPU excecution trace and pumps it into CoreSight
AMBA Trace Bus and is collected by a different CoreSight component
(traditionally CoreSight TMC-ETR /ETB/ETF), called "sink".
Important to note that there is no guarantee that every CPU has
a dedicated sink. Thus multiple ETMs could pump the trace data
into the same "sink" and thus they apply additional formatting
of the trace data for the user to decode it properly and attribute
the trace data to the corresponding ETM.
However, with the introduction of Arm Trace buffer Extensions (TRBE),
we now have a dedicated per-CPU architected sink for collecting the
trace. Since the TRBE is always per-CPU, it doesn't apply any formatting
of the trace. The support for this driver is under review [1].
Now a system could have a per-cpu TRBE and one or more shared
TMC-ETRs on the system. A user could choose a "specific" sink
for a perf session (e.g, a TMC-ETR) or the driver could automatically
select the nearest sink for a given ETM. It is possible that
some ETMs could end up using TMC-ETR (e.g, if the TRBE is not
usable on the CPU) while the others using TRBE in a single
perf session. Thus we now have "formatted" trace collected
from TMC-ETR and "unformatted" trace collected from TRBE.
However, we don't get into a situation where a single event
could end up using TMC-ETR & TRBE. i.e, any AUX buffer is
guaranteed to be either RAW or FORMATTED, but not a mix
of both.
As for perf decoding, we need to know the type of the data
in the individual AUX buffers, so that it can set up the
"OpenCSD" (library for decoding CoreSight trace) decoder
instance appropriately. Thus the perf.data file must conatin
the hints for the tool to decode the data correctly.
Since this is a runtime variable, and perf tool doesn't have
a control on what sink gets used (in case of automatic sink
selection), we need this information made available from
the PMU driver for each AUX record.
# The_End_of_Story
Cc: Peter Ziljstra <peterz@infradead.org>
Cc: alexander.shishkin@linux.intel.com
Cc: mingo@redhat.com
Cc: will@kernel.org
Cc: mark.rutland@arm.com
Cc: mike.leach@linaro.org
Cc: acme@kernel.org
Cc: jolsa@redhat.com
Cc: Mathieu Poirier <redacted>
Reviewed by: Mike Leach [off-list ref]
Acked-by: Peter Ziljstra <peterz@infradead.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/uapi/linux/perf_event.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
@@ -1156,10 +1156,11 @@ enum perf_callchain_context {/***PERF_RECORD_AUX::flagsbits*/-#define PERF_AUX_FLAG_TRUNCATED 0x01 /* record was truncated to fit */-#define PERF_AUX_FLAG_OVERWRITE 0x02 /* snapshot from overwrite mode */-#define PERF_AUX_FLAG_PARTIAL 0x04 /* record contains gaps */-#define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */+#define PERF_AUX_FLAG_TRUNCATED 0x01 /* record was truncated to fit */+#define PERF_AUX_FLAG_OVERWRITE 0x02 /* snapshot from overwrite mode */+#define PERF_AUX_FLAG_PARTIAL 0x04 /* record contains gaps */+#define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */+#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK 0xff00 /* PMU specific trace format type */#define PERF_FLAG_FD_NO_GROUP (1UL << 0)#define PERF_FLAG_FD_OUTPUT (1UL << 1)
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:04
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/barrier.h | 1 +
1 file changed, 1 insertion(+)
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-24 09:40:07
On 23/03/2021 18:21, Catalin Marinas wrote:
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-24 13:50:39
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-24 15:51:57
On 24/03/2021 13:49, Marc Zyngier wrote:
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
Sorry for the confusion.
Kind regards
Suzuki
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-24 16:17:17
On Wed, 24 Mar 2021 15:51:14 +0000,
Suzuki K Poulose [off-list ref] wrote:
On 24/03/2021 13:49, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-24 16:26:17
On 24/03/2021 16:16, Marc Zyngier wrote:
On Wed, 24 Mar 2021 15:51:14 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 13:49, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
OK. I thought there was a need for these patches to prevent guest
access to the v8.4 self hosted tracing feature that went in 5.12
though[1]... Did I get it wrong?
Yes, that is correct. The guest could access the Trace Filter Control
register and fiddle with the host settings, without this patch.
e.g, it could disable tracing at EL0/EL1, without the host being
aware on nVHE host.
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-24 16:31:09
On Wed, 24 Mar 2021 16:25:12 +0000,
Suzuki K Poulose [off-list ref] wrote:
On 24/03/2021 16:16, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 15:51:14 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 13:49, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
OK. I thought there was a need for these patches to prevent guest
access to the v8.4 self hosted tracing feature that went in 5.12
though[1]... Did I get it wrong?
Yes, that is correct. The guest could access the Trace Filter Control
register and fiddle with the host settings, without this patch.
e.g, it could disable tracing at EL0/EL1, without the host being
aware on nVHE host.
OK, so we definitely do need these patches, don't we? Both? Just one?
Please have a look at kvmarm/fixes and tell me what I must keep.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-24 17:10:09
On 24/03/2021 16:30, Marc Zyngier wrote:
On Wed, 24 Mar 2021 16:25:12 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 16:16, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 15:51:14 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 13:49, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
OK. I thought there was a need for these patches to prevent guest
access to the v8.4 self hosted tracing feature that went in 5.12
though[1]... Did I get it wrong?
Yes, that is correct. The guest could access the Trace Filter Control
register and fiddle with the host settings, without this patch.
e.g, it could disable tracing at EL0/EL1, without the host being
aware on nVHE host.
OK, so we definitely do need these patches, don't we? Both? Just one?
Please have a look at kvmarm/fixes and tell me what I must keep.
Both of them are fixes.
commit "KVM: arm64: Disable guest access to trace filter controls"
- This fixes guest fiddling with the trace filter control as described
above.
commit "KVM: arm64: Hide system instruction access to Trace registers"
- Fixes the Hypervisor to advertise what it doesn't support. i.e
stop advertising trace system instruction access to a guest.
Otherwise a guest which trusts the ID registers
(ID_AA64DFR0_EL1.TRACEVER == 1) can crash while trying to access the
trace register as we trap the accesses (CPTR_EL2.TTA == 1). On Linux,
the ETM drivers need a DT explicitly advertising the support. So,
this is not immediately impacted. And this fix goes a long way back
in the history, when the CPTR_EL2.TTA was added.
Now, the reason for asking you to hold on is the way this could create
conflicts in merging the rest of the series.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Mar 24, 2021 at 05:06:58PM +0000, Suzuki K Poulose wrote:
On 24/03/2021 16:30, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 16:25:12 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 16:16, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 15:51:14 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 24/03/2021 13:49, Marc Zyngier wrote:
quoted
On Wed, 24 Mar 2021 09:39:13 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
On 23/03/2021 18:21, Catalin Marinas wrote:
quoted
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +0000, Suzuki K Poulose wrote:
quoted
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
How do you plan to merge these patches? If they go via the coresight
tree:
Ideally all of this should go via the CoreSight tree to have the
dependencies solved at one place. But there are some issues :
If this makes to 5.13 queue for CoreSight,
1) CoreSight next is based on rc2 at the moment and we have fixes gone
into rc3 and later, which this series will depend on. (We could move
the next tree forward to a later rc to solve this).
2) There could be conflicts with the kvmarm tree for the KVM host
changes (That has dependency on the TRBE definitions patch).
If it doesn't make to 5.13 queue, it would be good to have this patch,
the TRBE defintions and the KVM host patches queued for 5.13 (not sure
if this is acceptable) and we could rebase the CoreSight changes on 5.13
and push it to next release.
I am open for other suggestions.
Marc, Mathieu,
Thoughts ?
I was planning to take the first two patches in 5.12 as fixes (they
are queued already, and would hopefully land in -rc5). If that doesn't
fit with the plan, please let me know ASAP.
Marc,
I think it would be better to hold on pushing those patches until we
have a clarity on how things will go.
OK. I thought there was a need for these patches to prevent guest
access to the v8.4 self hosted tracing feature that went in 5.12
though[1]... Did I get it wrong?
Yes, that is correct. The guest could access the Trace Filter Control
register and fiddle with the host settings, without this patch.
e.g, it could disable tracing at EL0/EL1, without the host being
aware on nVHE host.
OK, so we definitely do need these patches, don't we? Both? Just one?
Please have a look at kvmarm/fixes and tell me what I must keep.
Both of them are fixes.
commit "KVM: arm64: Disable guest access to trace filter controls"
- This fixes guest fiddling with the trace filter control as described
above.
commit "KVM: arm64: Hide system instruction access to Trace registers"
- Fixes the Hypervisor to advertise what it doesn't support. i.e
stop advertising trace system instruction access to a guest.
Otherwise a guest which trusts the ID registers
(ID_AA64DFR0_EL1.TRACEVER == 1) can crash while trying to access the
trace register as we trap the accesses (CPTR_EL2.TTA == 1). On Linux,
the ETM drivers need a DT explicitly advertising the support. So,
this is not immediately impacted. And this fix goes a long way back
in the history, when the CPTR_EL2.TTA was added.
Now, the reason for asking you to hold on is the way this could create
conflicts in merging the rest of the series.
The way we normally work around this is to either rebase your series on
top of -rc5 when the fixes go in or, if you want an earlier -rc base,
Marc can put them on a stable branch somewhere that you can use.
In the worst case you can merge the patches twice but that's rarely
needed.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-24 17:41:35
On Wed, 24 Mar 2021 17:19:36 +0000,
Catalin Marinas [off-list ref] wrote:
On Wed, Mar 24, 2021 at 05:06:58PM +0000, Suzuki K Poulose wrote:
quoted
On 24/03/2021 16:30, Marc Zyngier wrote:
quoted
OK, so we definitely do need these patches, don't we? Both? Just one?
Please have a look at kvmarm/fixes and tell me what I must keep.
Both of them are fixes.
commit "KVM: arm64: Disable guest access to trace filter controls"
- This fixes guest fiddling with the trace filter control as described
above.
commit "KVM: arm64: Hide system instruction access to Trace registers"
- Fixes the Hypervisor to advertise what it doesn't support. i.e
stop advertising trace system instruction access to a guest.
Otherwise a guest which trusts the ID registers
(ID_AA64DFR0_EL1.TRACEVER == 1) can crash while trying to access the
trace register as we trap the accesses (CPTR_EL2.TTA == 1). On Linux,
the ETM drivers need a DT explicitly advertising the support. So,
this is not immediately impacted. And this fix goes a long way back
in the history, when the CPTR_EL2.TTA was added.
Now, the reason for asking you to hold on is the way this could create
conflicts in merging the rest of the series.
The way we normally work around this is to either rebase your series on
top of -rc5 when the fixes go in or, if you want an earlier -rc base,
Marc can put them on a stable branch somewhere that you can use.
Here's what I've done:
- the two patches are now on a branch[1] based off -rc3 which I
officially declare stable. Feel free to rebase your series on top.
- the KVM fixes branch now embeds this branch (yes, I've rebased it --
we'll hopefully survive the outrage).
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=trace-fixes-5.12
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Mar 24, 2021 at 05:40:39PM +0000, Marc Zyngier wrote:
On Wed, 24 Mar 2021 17:19:36 +0000,
Catalin Marinas [off-list ref] wrote:
quoted
On Wed, Mar 24, 2021 at 05:06:58PM +0000, Suzuki K Poulose wrote:
quoted
On 24/03/2021 16:30, Marc Zyngier wrote:
quoted
OK, so we definitely do need these patches, don't we? Both? Just one?
Please have a look at kvmarm/fixes and tell me what I must keep.
Both of them are fixes.
commit "KVM: arm64: Disable guest access to trace filter controls"
- This fixes guest fiddling with the trace filter control as described
above.
commit "KVM: arm64: Hide system instruction access to Trace registers"
- Fixes the Hypervisor to advertise what it doesn't support. i.e
stop advertising trace system instruction access to a guest.
Otherwise a guest which trusts the ID registers
(ID_AA64DFR0_EL1.TRACEVER == 1) can crash while trying to access the
trace register as we trap the accesses (CPTR_EL2.TTA == 1). On Linux,
the ETM drivers need a DT explicitly advertising the support. So,
this is not immediately impacted. And this fix goes a long way back
in the history, when the CPTR_EL2.TTA was added.
Now, the reason for asking you to hold on is the way this could create
conflicts in merging the rest of the series.
The way we normally work around this is to either rebase your series on
top of -rc5 when the fixes go in or, if you want an earlier -rc base,
Marc can put them on a stable branch somewhere that you can use.
Here's what I've done:
- the two patches are now on a branch[1] based off -rc3 which I
officially declare stable. Feel free to rebase your series on top.
- the KVM fixes branch now embeds this branch (yes, I've rebased it --
we'll hopefully survive the outrage).
We don't have a choice to rebase. I will rebased CS next on [1] and
apply this set on top of it. Hopefully the KVM fixes will have made it to GKH's
char-misc tree by the time I send him the patches for the next merge window.
Otherwise we'll have to merge patches twice as Catalin mentioned. We can deal
with that if/when we get there.
Thanks,
Mathieu
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:04
CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ETMs, with the TraceID to indicate
the source of a given trace packet.
Arm Trace Buffer Extension is new "sink" IP, attached to individual
CPUs and thus do not provide additional formatting, like TMC-ETR.
Additionally, a system could have both TRBE *and* TMC-ETR for
the trace collection. e.g, TMC-ETR could be used as a single
trace buffer to collect data from multiple ETMs to correlate
the traces from different CPUs. It is possible to have a
perf session where some events end up collecting the trace
in TMC-ETR while the others in TRBE. Thus we need a way
to identify the type of the trace for each AUX record.
Define the trace formats exported by the CoreSight PMU.
We don't define the flags following the "ETM" as this
information is available to the user when issuing
the session. What is missing is the additional
formatting applied by the "sink" which is decided
at the runtime and the user may not have a control on.
So we define :
- CORESIGHT format (indicates the Frame format)
- RAW format (indicates the format of the source)
The default value is CORESIGHT format for all the records
(i,e == 0). Add the RAW format for others that use
raw format.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Leach <redacted>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Leo Yan <redacted>
Cc: Anshuman Khandual <redacted>
Reviewed-by: Mike Leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/uapi/linux/perf_event.h | 4 ++++
1 file changed, 4 insertions(+)
Hi Peter,
On Tue, Mar 23, 2021 at 12:06:32PM +0000, Suzuki K Poulose wrote:
quoted hunk
CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ETMs, with the TraceID to indicate
the source of a given trace packet.
Arm Trace Buffer Extension is new "sink" IP, attached to individual
CPUs and thus do not provide additional formatting, like TMC-ETR.
Additionally, a system could have both TRBE *and* TMC-ETR for
the trace collection. e.g, TMC-ETR could be used as a single
trace buffer to collect data from multiple ETMs to correlate
the traces from different CPUs. It is possible to have a
perf session where some events end up collecting the trace
in TMC-ETR while the others in TRBE. Thus we need a way
to identify the type of the trace for each AUX record.
Define the trace formats exported by the CoreSight PMU.
We don't define the flags following the "ETM" as this
information is available to the user when issuing
the session. What is missing is the additional
formatting applied by the "sink" which is decided
at the runtime and the user may not have a control on.
So we define :
- CORESIGHT format (indicates the Frame format)
- RAW format (indicates the format of the source)
The default value is CORESIGHT format for all the records
(i,e == 0). Add the RAW format for others that use
raw format.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Leach <redacted>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Leo Yan <redacted>
Cc: Anshuman Khandual <redacted>
Reviewed-by: Mike Leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/uapi/linux/perf_event.h | 4 ++++
1 file changed, 4 insertions(+)
@@ -1162,6 +1162,10 @@ enum perf_callchain_context {#define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK 0xff00 /* PMU specific trace format type */+/* CoreSight PMU AUX buffer formats */+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT 0x0000 /* Default for backward compatibility */+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW 0x0100 /* Raw format of the source */+
Have you had time to review this patch? Anything you'd like to see modified?
Thanks,
Mathieu
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-04-19 07:47:27
On Mon, Mar 29, 2021 at 10:56:25AM -0600, Mathieu Poirier wrote:
Hi Peter,
On Tue, Mar 23, 2021 at 12:06:32PM +0000, Suzuki K Poulose wrote:
quoted
CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ETMs, with the TraceID to indicate
the source of a given trace packet.
Arm Trace Buffer Extension is new "sink" IP, attached to individual
CPUs and thus do not provide additional formatting, like TMC-ETR.
Additionally, a system could have both TRBE *and* TMC-ETR for
the trace collection. e.g, TMC-ETR could be used as a single
trace buffer to collect data from multiple ETMs to correlate
the traces from different CPUs. It is possible to have a
perf session where some events end up collecting the trace
in TMC-ETR while the others in TRBE. Thus we need a way
to identify the type of the trace for each AUX record.
Define the trace formats exported by the CoreSight PMU.
We don't define the flags following the "ETM" as this
information is available to the user when issuing
the session. What is missing is the additional
formatting applied by the "sink" which is decided
at the runtime and the user may not have a control on.
So we define :
- CORESIGHT format (indicates the Frame format)
- RAW format (indicates the format of the source)
The default value is CORESIGHT format for all the records
(i,e == 0). Add the RAW format for others that use
raw format.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Leach <redacted>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Leo Yan <redacted>
Cc: Anshuman Khandual <redacted>
Reviewed-by: Mike Leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/uapi/linux/perf_event.h | 4 ++++
1 file changed, 4 insertions(+)
@@ -1162,6 +1162,10 @@ enum perf_callchain_context {#define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK 0xff00 /* PMU specific trace format type */+/* CoreSight PMU AUX buffer formats */+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT 0x0000 /* Default for backward compatibility */+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW 0x0100 /* Raw format of the source */+
Have you had time to review this patch? Anything you'd like to see modified?
Ok I suppose..
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:04
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
@@ -58,10 +58,51 @@ static void __debug_restore_spe(u64 pmscr_el1)write_sysreg_s(pmscr_el1,SYS_PMSCR_EL1);}+staticvoid__debug_save_trace(u64*trfcr_el1)+{++*trfcr_el1=0;++/* Check if we have TRBE */+if(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),+ID_AA64DFR0_TRBE_SHIFT))+return;++/* Check we can access the TRBE */+if((read_sysreg_s(SYS_TRBIDR_EL1)&TRBIDR_PROG))+return;++/* Check if the TRBE is enabled */+if(!(read_sysreg_s(SYS_TRBLIMITR_EL1)&TRBLIMITR_ENABLE))+return;+/*+*Prohibittracegenerationwhileweareinguest.+*SinceaccesstoTRFCR_EL1istrapped,theguestcan't+*modifythefilteringsetbythehost.+*/+*trfcr_el1=read_sysreg_s(SYS_TRFCR_EL1);+write_sysreg_s(0,SYS_TRFCR_EL1);+isb();+/* Drain the trace buffer to memory */+tsb_csync();+dsb(nsh);+}++staticvoid__debug_restore_trace(u64trfcr_el1)+{+if(!trfcr_el1)+return;++/* Restore trace filter controls */+write_sysreg_s(trfcr_el1,SYS_TRFCR_EL1);+}+void__debug_save_host_buffers_nvhe(structkvm_vcpu*vcpu){/* Disable and flush SPE data generation */__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);+/* Disable and flush Self-Hosted Trace generation */+__debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1);}void__debug_switch_to_guest(structkvm_vcpu*vcpu)
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
@@ -58,10 +58,51 @@ static void __debug_restore_spe(u64 pmscr_el1)write_sysreg_s(pmscr_el1,SYS_PMSCR_EL1);}+staticvoid__debug_save_trace(u64*trfcr_el1)+{++*trfcr_el1=0;++/* Check if we have TRBE */+if(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),+ID_AA64DFR0_TRBE_SHIFT))+return;++/* Check we can access the TRBE */+if((read_sysreg_s(SYS_TRBIDR_EL1)&TRBIDR_PROG))+return;++/* Check if the TRBE is enabled */+if(!(read_sysreg_s(SYS_TRBLIMITR_EL1)&TRBLIMITR_ENABLE))+return;+/*+*Prohibittracegenerationwhileweareinguest.+*SinceaccesstoTRFCR_EL1istrapped,theguestcan't+*modifythefilteringsetbythehost.+*/+*trfcr_el1=read_sysreg_s(SYS_TRFCR_EL1);+write_sysreg_s(0,SYS_TRFCR_EL1);+isb();+/* Drain the trace buffer to memory */+tsb_csync();+dsb(nsh);+}++staticvoid__debug_restore_trace(u64trfcr_el1)+{+if(!trfcr_el1)+return;++/* Restore trace filter controls */+write_sysreg_s(trfcr_el1,SYS_TRFCR_EL1);+}+void__debug_save_host_buffers_nvhe(structkvm_vcpu*vcpu){/* Disable and flush SPE data generation */__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);+/* Disable and flush Self-Hosted Trace generation */+__debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1);}void__debug_switch_to_guest(structkvm_vcpu*vcpu)
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 10:17:25
Hi Mathieu,
On Fri, 26 Mar 2021 16:55:50 +0000,
Mathieu Poirier [off-list ref] wrote:
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I just went through the KVM patch, and I have a couple of question
that Suzuki can hopefully address quickly enough. As for merging it
via your tree, I'm worried that it will conflict with other patches
that are in flight.
We can hopefully set up a stable branch between the two trees.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-30 10:39:15
On 26/03/2021 16:55, Mathieu Poirier wrote:
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the
amount of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued
in v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
Thoughts ?
Suzuki
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
@@ -58,10 +58,51 @@ static void __debug_restore_spe(u64 pmscr_el1)write_sysreg_s(pmscr_el1,SYS_PMSCR_EL1);}+staticvoid__debug_save_trace(u64*trfcr_el1)+{++*trfcr_el1=0;++/* Check if we have TRBE */+if(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),+ID_AA64DFR0_TRBE_SHIFT))+return;++/* Check we can access the TRBE */+if((read_sysreg_s(SYS_TRBIDR_EL1)&TRBIDR_PROG))+return;++/* Check if the TRBE is enabled */+if(!(read_sysreg_s(SYS_TRBLIMITR_EL1)&TRBLIMITR_ENABLE))+return;+/*+*Prohibittracegenerationwhileweareinguest.+*SinceaccesstoTRFCR_EL1istrapped,theguestcan't+*modifythefilteringsetbythehost.+*/+*trfcr_el1=read_sysreg_s(SYS_TRFCR_EL1);+write_sysreg_s(0,SYS_TRFCR_EL1);+isb();+/* Drain the trace buffer to memory */+tsb_csync();+dsb(nsh);+}++staticvoid__debug_restore_trace(u64trfcr_el1)+{+if(!trfcr_el1)+return;++/* Restore trace filter controls */+write_sysreg_s(trfcr_el1,SYS_TRFCR_EL1);+}+void__debug_save_host_buffers_nvhe(structkvm_vcpu*vcpu){/* Disable and flush SPE data generation */__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);+/* Disable and flush Self-Hosted Trace generation */+__debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1);}void__debug_switch_to_guest(structkvm_vcpu*vcpu)
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so. The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window. When that
is done we add the ETE/TRBE for the v5.14 merge window. I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
@@ -58,10 +58,51 @@ static void __debug_restore_spe(u64 pmscr_el1)write_sysreg_s(pmscr_el1,SYS_PMSCR_EL1);}+staticvoid__debug_save_trace(u64*trfcr_el1)+{++*trfcr_el1=0;++/* Check if we have TRBE */+if(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),+ID_AA64DFR0_TRBE_SHIFT))+return;++/* Check we can access the TRBE */+if((read_sysreg_s(SYS_TRBIDR_EL1)&TRBIDR_PROG))+return;++/* Check if the TRBE is enabled */+if(!(read_sysreg_s(SYS_TRBLIMITR_EL1)&TRBLIMITR_ENABLE))+return;+/*+*Prohibittracegenerationwhileweareinguest.+*SinceaccesstoTRFCR_EL1istrapped,theguestcan't+*modifythefilteringsetbythehost.+*/+*trfcr_el1=read_sysreg_s(SYS_TRFCR_EL1);+write_sysreg_s(0,SYS_TRFCR_EL1);+isb();+/* Drain the trace buffer to memory */+tsb_csync();+dsb(nsh);+}++staticvoid__debug_restore_trace(u64trfcr_el1)+{+if(!trfcr_el1)+return;++/* Restore trace filter controls */+write_sysreg_s(trfcr_el1,SYS_TRFCR_EL1);+}+void__debug_save_host_buffers_nvhe(structkvm_vcpu*vcpu){/* Disable and flush SPE data generation */__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);+/* Disable and flush Self-Hosted Trace generation */+__debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1);}void__debug_switch_to_guest(structkvm_vcpu*vcpu)
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 15:35:28
On Tue, 30 Mar 2021 16:23:14 +0100,
Mathieu Poirier [off-list ref] wrote:
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
quoted
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
quoted
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and
rightly so.
We do that all the times. Otherwise, it is hardly possible to build an
infrastructure that spans across multiple subsystems *and* involves
userspace. I really wouldn't worry about that.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 30, 2021 at 09:23:14AM -0600, Mathieu Poirier wrote:
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
quoted
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
My tree can not be based on -next, and neither can any other
maintainer's tree, as next is composed of maintainer trees :)
quoted
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so. The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window. When that
is done we add the ETE/TRBE for the v5.14 merge window. I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.
Or someone creates a single branch with a signed tag and it gets pulled
into multiple maintainer's trees and never rebased. We've done that
lots of time, nothing new there. Or everything goes through one tree,
or you wait a release cycle.
You have 3 choices, pick one :)
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, 30 Mar 2021 at 09:35, Greg KH [off-list ref] wrote:
On Tue, Mar 30, 2021 at 09:23:14AM -0600, Mathieu Poirier wrote:
quoted
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
quoted
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
My tree can not be based on -next, and neither can any other
maintainer's tree, as next is composed of maintainer trees :)
Exactly
quoted
quoted
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so. The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window. When that
is done we add the ETE/TRBE for the v5.14 merge window. I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.
Or someone creates a single branch with a signed tag and it gets pulled
into multiple maintainer's trees and never rebased. We've done that
lots of time, nothing new there. Or everything goes through one tree,
or you wait a release cycle.
You have 3 choices, pick one :)
I'm perfectly happy with getting this entire set merged via Marc's
kvmarm tree, as long as you are fine with it.
On Tue, Mar 30, 2021 at 10:33:51AM -0600, Mathieu Poirier wrote:
On Tue, 30 Mar 2021 at 09:35, Greg KH [off-list ref] wrote:
quoted
On Tue, Mar 30, 2021 at 09:23:14AM -0600, Mathieu Poirier wrote:
quoted
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
quoted
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
My tree can not be based on -next, and neither can any other
maintainer's tree, as next is composed of maintainer trees :)
Exactly
quoted
quoted
quoted
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so. The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window. When that
is done we add the ETE/TRBE for the v5.14 merge window. I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.
Or someone creates a single branch with a signed tag and it gets pulled
into multiple maintainer's trees and never rebased. We've done that
lots of time, nothing new there. Or everything goes through one tree,
or you wait a release cycle.
You have 3 choices, pick one :)
I'm perfectly happy with getting this entire set merged via Marc's
kvmarm tree, as long as you are fine with it.
No objection from me at all for this to go that way.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, 30 Mar 2021 at 10:47, Greg KH [off-list ref] wrote:
On Tue, Mar 30, 2021 at 10:33:51AM -0600, Mathieu Poirier wrote:
quoted
On Tue, 30 Mar 2021 at 09:35, Greg KH [off-list ref] wrote:
quoted
On Tue, Mar 30, 2021 at 09:23:14AM -0600, Mathieu Poirier wrote:
quoted
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
quoted
On 26/03/2021 16:55, Mathieu Poirier wrote:
quoted
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount
of changes the tree is going through, in the areas this patch
touches. Or else there would be conflicts with merging. And this patch
depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in
v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b)
(d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at
runtime.
So, if :
kvmarm tree picks up : b + c
coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in
kvmarm
greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it
is a while before other branches like kvmarm get merged, causing all sort of
compilation breakage.
My tree can not be based on -next, and neither can any other
maintainer's tree, as next is composed of maintainer trees :)
Exactly
quoted
quoted
quoted
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch
and add it only at the rc1, once we verify both the trees are in to make
sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so. The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window. When that
is done we add the ETE/TRBE for the v5.14 merge window. I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.
Or someone creates a single branch with a signed tag and it gets pulled
into multiple maintainer's trees and never rebased. We've done that
lots of time, nothing new there. Or everything goes through one tree,
or you wait a release cycle.
You have 3 choices, pick one :)
I'm perfectly happy with getting this entire set merged via Marc's
kvmarm tree, as long as you are fine with it.
No objection from me at all for this to go that way.
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 10:13:05
Hi Suzuki,
[+ Alex]
On Tue, 23 Mar 2021 12:06:35 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted hunk
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
For the record, this is likely to conflict with [1], although that
patch still has some issues.
quoted hunk
*
* Additionally, KVM only traps guest accesses to the debug registers if
* the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -107,8 +107,8 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug); /*- * This also clears MDCR_EL2_E2PB_MASK to disable guest access- * to the profiling buffer.+ * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK+ * to disable guest access to the profiling and trace buffers */ vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+ *trfcr_el1 = 0;
+
+ /* Check if we have TRBE */
+ if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
+ ID_AA64DFR0_TRBE_SHIFT))
+ return;
Do we have a way to track this that doesn't involve reading an ID
register? This is on the hot path, and is going to really suck badly
with NV (which traps all ID regs for obvious reasons). I would have
hoped that one way or another, we'd have a static key for this.
+
+ /* Check we can access the TRBE */
+ if ((read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_PROG))
+ return;
+
+ /* Check if the TRBE is enabled */
+ if (!(read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_ENABLE))
+ return;
+ /*
+ * Prohibit trace generation while we are in guest.
+ * Since access to TRFCR_EL1 is trapped, the guest can't
+ * modify the filtering set by the host.
If TRFCR_EL1 is trapped, where is the trap handling? This series
doesn't touch sys_regs.c, so I assume you rely on the "inject an UNDEF
for anything unknown" default behaviour?
If that's the case, I'd rather you add an explicit handler.
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-30 11:13:55
Hi Marc
On 30/03/2021 11:12, Marc Zyngier wrote:
Hi Suzuki,
[+ Alex]
On Tue, 23 Mar 2021 12:06:35 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endm
For the record, this is likely to conflict with [1], although that
patch still has some issues.
Thanks for the heads up. I think that patch will also conflict with my
fixes that is queued in kvmarm/fixes.
quoted
*
* Additionally, KVM only traps guest accesses to the debug registers if
* the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -107,8 +107,8 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug); /*- * This also clears MDCR_EL2_E2PB_MASK to disable guest access- * to the profiling buffer.+ * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK+ * to disable guest access to the profiling and trace buffers */ vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+ *trfcr_el1 = 0;
+
+ /* Check if we have TRBE */
+ if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
+ ID_AA64DFR0_TRBE_SHIFT))
+ return;
Do we have a way to track this that doesn't involve reading an ID
register? This is on the hot path, and is going to really suck badly
with NV (which traps all ID regs for obvious reasons). I would have
hoped that one way or another, we'd have a static key for this.
TRBE, like SPE can be optionally enabled on a subset of the CPUs. We
could have a per-CPU static key in the worst case. I guess this would
apply to SPE as well.
May be we could do this check at kvm_arch_vcpu_load()/put() ?
quoted
+
+ /* Check we can access the TRBE */
+ if ((read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_PROG))
+ return;
+
+ /* Check if the TRBE is enabled */
+ if (!(read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_ENABLE))
+ return;
+ /*
+ * Prohibit trace generation while we are in guest.
+ * Since access to TRFCR_EL1 is trapped, the guest can't
+ * modify the filtering set by the host.
If TRFCR_EL1 is trapped, where is the trap handling? This series
doesn't touch sys_regs.c, so I assume you rely on the "inject an UNDEF
for anything unknown" default behaviour?
Yes.
If that's the case, I'd rather you add an explicit handler.
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 12:15:59
On Tue, 30 Mar 2021 12:12:49 +0100,
Suzuki K Poulose [off-list ref] wrote:
Hi Marc
On 30/03/2021 11:12, Marc Zyngier wrote:
quoted
Hi Suzuki,
[+ Alex]
On Tue, 23 Mar 2021 12:06:35 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endmdiff--gita/arch/arm64/include/asm/kvm_arm.h
b/arch/arm64/include/asm/kvm_arm.h
index 94d4025acc0b..692c9049befa 100644
For the record, this is likely to conflict with [1], although that
patch still has some issues.
Thanks for the heads up. I think that patch will also conflict with my
fixes that is queued in kvmarm/fixes.
Most probably. This is a popular landing spot, these days...
quoted
quoted
*
* Additionally, KVM only traps guest accesses to the debug registers if
* the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -107,8 +107,8 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug); /*- * This also clears MDCR_EL2_E2PB_MASK to disable guest access- * to the profiling buffer.+ * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK+ * to disable guest access to the profiling and trace buffers */ vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+ *trfcr_el1 = 0;
+
+ /* Check if we have TRBE */
+ if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
+ ID_AA64DFR0_TRBE_SHIFT))
+ return;
Do we have a way to track this that doesn't involve reading an ID
register? This is on the hot path, and is going to really suck badly
with NV (which traps all ID regs for obvious reasons). I would have
hoped that one way or another, we'd have a static key for this.
TRBE, like SPE can be optionally enabled on a subset of the CPUs. We
could have a per-CPU static key in the worst case. I guess this would
apply to SPE as well.
Ah, so you want to support asymmetric tracing... fair enough. But I
don't think you need a per-CPU static key (and I'm not sure how that'd
work either). You could have a static key indicating if *any* CPU
implements tracing, in which case the check only happens when at least
one CPU is capable of tracing.
You would only need a new capability.
May be we could do this check at kvm_arch_vcpu_load()/put() ?
That would extend the tracing blackout period enormously, wouldn't it?
I'm not sure that's the best thing to do...
quoted
quoted
+
+ /* Check we can access the TRBE */
+ if ((read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_PROG))
+ return;
+
+ /* Check if the TRBE is enabled */
+ if (!(read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_ENABLE))
+ return;
+ /*
+ * Prohibit trace generation while we are in guest.
+ * Since access to TRFCR_EL1 is trapped, the guest can't
+ * modify the filtering set by the host.
If TRFCR_EL1 is trapped, where is the trap handling? This series
doesn't touch sys_regs.c, so I assume you rely on the "inject an UNDEF
for anything unknown" default behaviour?
Yes.
quoted
If that's the case, I'd rather you add an explicit handler.
I could add one.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-30 13:35:38
On 30/03/2021 13:15, Marc Zyngier wrote:
On Tue, 30 Mar 2021 12:12:49 +0100,
Suzuki K Poulose [off-list ref] wrote:
quoted
Hi Marc
On 30/03/2021 11:12, Marc Zyngier wrote:
quoted
Hi Suzuki,
[+ Alex]
On Tue, 23 Mar 2021 12:06:35 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <redacted>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/el2_setup.h | 13 +++++++++
arch/arm64/include/asm/kvm_arm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kernel/hyp-stub.S | 3 ++-
arch/arm64/kvm/debug.c | 6 ++---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 1 +
7 files changed, 65 insertions(+), 4 deletions(-)
@@ -65,6 +65,19 @@// use EL1&0 translation..Lskip_spe_\@:+/* Trace buffer */+ubfxx0,x1,#ID_AA64DFR0_TRBE_SHIFT,#4+cbzx0,.Lskip_trace_\@// Skip if TraceBuffer is not present++mrs_sx0,SYS_TRBIDR_EL1+andx0,x0,TRBIDR_PROG+cbnzx0,.Lskip_trace_\@// If TRBE is available at EL2++movx0,#(MDCR_EL2_E2TB_MASK<<MDCR_EL2_E2TB_SHIFT)+orrx2,x2,x0// allow the EL1&0 translation+// to own it.++.Lskip_trace_\@:msrmdcr_el2,x2// Configure debug traps.endmdiff--gita/arch/arm64/include/asm/kvm_arm.h
b/arch/arm64/include/asm/kvm_arm.h
index 94d4025acc0b..692c9049befa 100644
For the record, this is likely to conflict with [1], although that
patch still has some issues.
Thanks for the heads up. I think that patch will also conflict with my
fixes that is queued in kvmarm/fixes.
Most probably. This is a popular landing spot, these days...
quoted
quoted
quoted
*
* Additionally, KVM only traps guest accesses to the debug registers if
* the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -107,8 +107,8 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug); /*- * This also clears MDCR_EL2_E2PB_MASK to disable guest access- * to the profiling buffer.+ * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK+ * to disable guest access to the profiling and trace buffers */ vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+ *trfcr_el1 = 0;
+
+ /* Check if we have TRBE */
+ if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
+ ID_AA64DFR0_TRBE_SHIFT))
+ return;
Do we have a way to track this that doesn't involve reading an ID
register? This is on the hot path, and is going to really suck badly
with NV (which traps all ID regs for obvious reasons). I would have
hoped that one way or another, we'd have a static key for this.
TRBE, like SPE can be optionally enabled on a subset of the CPUs. We
could have a per-CPU static key in the worst case. I guess this would
apply to SPE as well.
Ah, so you want to support asymmetric tracing... fair enough. But I
don't think you need a per-CPU static key (and I'm not sure how that'd
work either). You could have a static key indicating if *any* CPU
implements tracing, in which case the check only happens when at least
one CPU is capable of tracing.
You would only need a new capability.
quoted
May be we could do this check at kvm_arch_vcpu_load()/put() ?
That would extend the tracing blackout period enormously, wouldn't it?
I'm not sure that's the best thing to do...
Sorry for not making this clear. We could check if the SPE/TRBE is
available on this CPU (including the PMB/TRB_IDR bits and a set a flag
in the VCPU on every kvm_arch_vcpu_load() and cleared on put.
The actual switching code could check this flag and check if the unit
is enabled and then do the actual save/restore as we do below.
(We may be able to even check if unit is enabled there, need to double
check this.)
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:00:57
On Tue, 30 Mar 2021 14:34:23 +0100,
Suzuki K Poulose [off-list ref] wrote:
On 30/03/2021 13:15, Marc Zyngier wrote:
quoted
On Tue, 30 Mar 2021 12:12:49 +0100,
Suzuki K Poulose [off-list ref] wrote:
[...]
quoted
quoted
May be we could do this check at kvm_arch_vcpu_load()/put() ?
That would extend the tracing blackout period enormously, wouldn't it?
I'm not sure that's the best thing to do...
Sorry for not making this clear. We could check if the SPE/TRBE is
available on this CPU (including the PMB/TRB_IDR bits and a set a flag
in the VCPU on every kvm_arch_vcpu_load() and cleared on put.
The actual switching code could check this flag and check if the unit
is enabled and then do the actual save/restore as we do below.
(We may be able to even check if unit is enabled there, need to double
check this.)
Ah, gotcha. Yes, this seems like a reasonable thing to do. We have the
per-vcpu debug flags already, and you could piggy-back on that.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
mrs_s x0, SYS_VBAR_EL12
msr vbar_el1, x0
- // Use EL2 translations for SPE and disable access from EL1
+ // Use EL2 translations for SPE & TRBE and disable access from EL1
mrs x0, mdcr_el2
bic x0, x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+ bic x0, x0, #(MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT)
msr mdcr_el2, x0
// Transfer the MM state from EL1 to EL2
mrs_s x0, SYS_VBAR_EL12
msr vbar_el1, x0
- // Use EL2 translations for SPE and disable access from EL1
+ // Use EL2 translations for SPE & TRBE and disable access from EL1
mrs x0, mdcr_el2
bic x0, x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+ bic x0, x0, #(MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT)
msr mdcr_el2, x0
// Transfer the MM state from EL1 to EL2
For the record, this is likely to conflict with [1], although that
patch still has some issues.
Thanks for the heads up. I think that patch will also conflict with my fixes
that is queued in kvmarm/fixes.
How should I proceed with the patch [1]? For the next iteration, should I rebase
it on top of kvmarm/fixes or on top of kvmarm/fixes + this series?
On top of kvmarm/fixes, please. I'll merge that branch into 5.13
anyway, as it is taking some time to land upstream.
I'll take care of the conflicts, and shout if I need help!
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:04
When a sink is not specified by the user, the etm perf driver
finds a suitable sink automatically, based on the first ETM
where this event could be scheduled. Then we allocate the
sink buffer based on the selected sink. This is fine for a
CPU bound event as the "sink" is always guaranteed to be
reachable from the ETM (as this is the only ETM where the
event is going to be scheduled). However, if we have a thread
bound event, the event could be scheduled on any of the ETMs
on the system. In this case, currently we automatically select
a sink and exclude any ETMs that cannot reach the selected
sink. This is problematic especially for 1x1 configurations.
We end up in tracing the event only on the "first" ETM,
as the default sink is local to the first ETM and unreachable
from the rest. However, we could allow the other ETMs to
trace if they all have a sink that is compatible with the
"selected" sink and can use the sink buffer. This can be
easily done by verifying that they are all driven by the
same driver and matches the same subtype. Please note
that at anytime there can be only one ETM tracing the event.
Adding support for different types of sinks for a single
event is complex and is not something that we expect
on a sane configuration.
Cc: Anshuman Khandual <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Mike Leach <redacted>
Tested-by: Linu Cherian <redacted>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
.../hwtracing/coresight/coresight-etm-perf.c | 60 ++++++++++++++++---
1 file changed, 52 insertions(+), 8 deletions(-)
@@ -249,7 +269,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,/* First get the selected sink from user space. */if(event->attr.config2){id=(u32)event->attr.config2;-sink=coresight_get_sink_by_id(id);+sink=user_sink=coresight_get_sink_by_id(id);}mask=&event_data->mask;
@@ -277,14 +297,33 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,}/*-*Nosinkprovided-lookforadefaultsinkforoneofthe-*devices.AtpresentweonlysupporttopologywhereallCPUs-*usethesamesink[N:1],soonlyneedtofindonesink.The-*coresight_build_pathlaterwillremoveanyCPUthatdoesnot-*attachtothesink,orifwehavenotfoundasink.+*Nosinkprovided-lookforadefaultsinkforalltheETMs,+*wherethiseventcanbescheduled.+*Weallocatethesinkspecificbuffersonlyonceforthis+*event.IftheETMshavedifferentdefaultsinkdevices,we+*canonlyuseasingle"type"ofsinkastheeventcancarry+*onlyonesinkspecificbuffer.Thuswehavetomakesure+*thatthesinksareofthesametypeanddrivenbythesame+*driver,astheoneweallocatethebufferfor.Assuch+*wechoosethefirstsinkandcheckiftheremainingETMs+*haveacompatibledefaultsink.Wedon'ttraceonaCPU+*ifthesinkisnotcompatible.*/-if(!sink)+if(!user_sink){+/* Find the default sink for this ETM */sink=coresight_find_default_sink(csdev);+if(!sink){+cpumask_clear_cpu(cpu,mask);+continue;+}++/* Check if this sink compatible with the last sink */+if(last_sink&&!sinks_compatible(last_sink,sink)){+cpumask_clear_cpu(cpu,mask);+continue;+}+last_sink=sink;+}/**Buildingapathdoesn'tenableit,itsimplybuildsa
@@ -312,7 +351,12 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,if(!sink_ops(sink)->alloc_buffer||!sink_ops(sink)->free_buffer)gotoerr;-/* Allocate the sink buffer for this session */+/*+*Allocatethesinkbufferforthissession.Allthesinks+*wherethiseventcanbescheduledareensuredtobeofthe+*sametype.Thusthesamesinkconfigurationisusedbythe+*sinks.+*/event_data->snk_config=sink_ops(sink)->alloc_buffer(sink,event,pages,nr_pages,overwrite);
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -654,6 +655,7 @@ static int etm4_enable(struct coresight_device *csdev,staticvoidetm4_disable_hw(void*info){u32control;+u64trfcr;structetmv4_drvdata*drvdata=info;structetmv4_config*config=&drvdata->config;structcoresight_device*csdev=drvdata->csdev;
@@ -676,6 +678,16 @@ static void etm4_disable_hw(void *info)/* EN, bit[0] Trace unit enable bit */control&=~0x1;+/*+*IftheCPUsupportsv8.4TracefilterControl,+*settheETMtotraceprohibitedregion.+*/+if(drvdata->trfc){+trfcr=read_sysreg_s(SYS_TRFCR_EL1);+write_sysreg_s(trfcr&~(TRFCR_ELx_ExTRE|TRFCR_ELx_E0TRE),+SYS_TRFCR_EL1);+isb();+}/**Makesureeverythingcompletesbeforedisabling,asrecommended*bysection7.3.77("TRCVICTLR, ViewInst Main Control Register,
@@ -683,12 +695,16 @@ static void etm4_disable_hw(void *info)*/dsb(sy);isb();+/* Trace synchronization barrier, is a nop if not supported */+tsb_csync();etm4x_relaxed_write32(csa,control,TRCPRGCTLR);/* wait for TRCSTATR.PMSTABLE to go to '1' */if(coresight_timeout(csa,TRCSTATR,TRCSTATR_PMSTABLE_BIT,1))dev_err(etm_dev,"timeout while waiting for PM stable Trace Status\n");+if(drvdata->trfc)+write_sysreg_s(trfcr,SYS_TRFCR_EL1);/* read the status of the single shot comparators */for(i=0;i<drvdata->nr_ss_cmp;i++){
@@ -1082,7 +1099,7 @@ static void etm4_init_arch_data(void *info)/* NUMCNTR, bits[30:28] number of counters available for tracing */drvdata->nr_cntr=BMVAL(etmidr5,28,30);etm4_cs_lock(drvdata,csa);-cpu_enable_tracing();+cpu_enable_tracing(drvdata);}staticinlineu32etm4_get_victlr_access_type(structetmv4_config*config)
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:04
If a graph node is not found for a given node, of_get_next_endpoint()
will emit the following error message :
OF: graph: no port node found in /<node_name>
If the given component doesn't have any explicit connections (e.g,
ETE) we could simply ignore the graph parsing. As for any legacy
component where this is mandatory, the device will not be usable
as before this patch. Updating the DT bindings to Yaml and enabling
the schema checks can detect such issues with the DT.
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight-platform.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:33
ETE may not implement the OS lock and instead could rely on
the PE OS Lock for the trace unit access. This is indicated
by the TRCOLSR.OSM == 0b100. Add support for handling the
PE OS lock
Cc: Mike Leach <redacted>
Reviewed-by: mike.leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
.../coresight/coresight-etm4x-core.c | 50 +++++++++++++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 15 ++++++
2 files changed, 56 insertions(+), 9 deletions(-)
@@ -115,30 +115,59 @@ void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)}}-staticvoidetm4_os_unlock_csa(structetmv4_drvdata*drvdata,structcsdev_access*csa)+staticvoidetm_detect_os_lock(structetmv4_drvdata*drvdata,+structcsdev_access*csa){-/* Writing 0 to TRCOSLAR unlocks the trace registers */-etm4x_relaxed_write32(csa,0x0,TRCOSLAR);-drvdata->os_unlock=true;+u32oslsr=etm4x_relaxed_read32(csa,TRCOSLSR);++drvdata->os_lock_model=ETM_OSLSR_OSLM(oslsr);+}++staticvoidetm_write_os_lock(structetmv4_drvdata*drvdata,+structcsdev_access*csa,u32val)+{+val=!!val;++switch(drvdata->os_lock_model){+caseETM_OSLOCK_PRESENT:+etm4x_relaxed_write32(csa,val,TRCOSLAR);+break;+caseETM_OSLOCK_PE:+write_sysreg_s(val,SYS_OSLAR_EL1);+break;+default:+pr_warn_once("CPU%d: Unsupported Trace OSLock model: %x\n",+smp_processor_id(),drvdata->os_lock_model);+fallthrough;+caseETM_OSLOCK_NI:+return;+}isb();}+staticinlinevoidetm4_os_unlock_csa(structetmv4_drvdata*drvdata,+structcsdev_access*csa)+{+WARN_ON(drvdata->cpu!=smp_processor_id());++/* Writing 0 to OS Lock unlocks the trace unit registers */+etm_write_os_lock(drvdata,csa,0x0);+drvdata->os_unlock=true;+}+staticvoidetm4_os_unlock(structetmv4_drvdata*drvdata){if(!WARN_ON(!drvdata->csdev))etm4_os_unlock_csa(drvdata,&drvdata->csdev->access);-}staticvoidetm4_os_lock(structetmv4_drvdata*drvdata){if(WARN_ON(!drvdata->csdev))return;--/* Writing 0x1 to TRCOSLAR locks the trace registers */-etm4x_relaxed_write32(&drvdata->csdev->access,0x1,TRCOSLAR);+/* Writing 0x1 to OS Lock locks the trace registers */+etm_write_os_lock(drvdata,&drvdata->csdev->access,0x1);drvdata->os_unlock=false;-isb();}staticvoidetm4_cs_lock(structetmv4_drvdata*drvdata,
@@ -937,6 +966,9 @@ static void etm4_init_arch_data(void *info)if(!etm4_init_csdev_access(drvdata,csa))return;+/* Detect the support for OS Lock before we actually use it */+etm_detect_os_lock(drvdata,csa);+/* Make sure all registers are accessible */etm4_os_unlock_csa(drvdata,csa);etm4_cs_unlock(drvdata,csa);
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:33
The context associated with an ETM for a given perf event
includes :
- handle -> the perf output handle for the AUX buffer.
- the path for the trace components
- the buffer config for the sink.
The path and the buffer config are part of the "aux_priv" data
(etm_event_data) setup by the setup_aux() callback, and made available
via perf_get_aux(handle).
Now with a sink supporting IRQ, the sink could "end" an output
handle when the buffer reaches the programmed limit and would try
to restart a handle. This could fail if there is not enough
space left the AUX buffer (e.g, the userspace has not consumed
the data). This leaves the "handle" disconnected from the "event"
and also the "perf_get_aux()" cleared. This all happens within
the sink driver, without the etm_perf driver being aware.
Now when the event is actually stopped, etm_event_stop()
will need to access the "event_data". But since the handle
is not valid anymore, we loose the information to stop the
"trace" path. So, we need a reliable way to access the etm_event_data
even when the handle may not be active.
This patch replaces the per_cpu handle array with a per_cpu context
for the ETM, which tracks the "handle" as well as the "etm_event_data".
The context notes the etm_event_data at etm_event_start() and clears
it at etm_event_stop(). This makes sure that we don't access a
stale "etm_event_data" as we are guaranteed that it is not
freed by free_aux() as long as the event is active and tracing,
also provides us with access to the critical information
needed to wind up a session even in the absence of an active
output_handle.
This is not an issue for the legacy sinks as none of them supports
an IRQ and is centrally handled by the etm-perf.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Anshuman Khandual <redacted>
Cc: Leo Yan <redacted>
Cc: Mike Leach <redacted>
Reviewed-by: Mike Leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
.../hwtracing/coresight/coresight-etm-perf.c | 59 +++++++++++++++++--
1 file changed, 54 insertions(+), 5 deletions(-)
@@ -376,13 +395,18 @@ static void etm_event_start(struct perf_event *event, int flags){intcpu=smp_processor_id();structetm_event_data*event_data;-structperf_output_handle*handle=this_cpu_ptr(&ctx_handle);+structetm_ctxt*ctxt=this_cpu_ptr(&etm_ctxt);+structperf_output_handle*handle=&ctxt->handle;structcoresight_device*sink,*csdev=per_cpu(csdev_src,cpu);structlist_head*path;if(!csdev)gotofail;+/* Have we messed up our tracking ? */+if(WARN_ON(ctxt->event_data))+gotofail;+/**DealwiththeringbufferAPIandgetahandleonthe*session'sinformation.
@@ -418,6 +442,8 @@ static void etm_event_start(struct perf_event *event, int flags)if(source_ops(csdev)->enable(csdev,event,CS_MODE_PERF))gotofail_disable_path;+/* Save the event_data for this ETM */+ctxt->event_data=event_data;out:return;
@@ -436,13 +462,30 @@ static void etm_event_stop(struct perf_event *event, int mode)intcpu=smp_processor_id();unsignedlongsize;structcoresight_device*sink,*csdev=per_cpu(csdev_src,cpu);-structperf_output_handle*handle=this_cpu_ptr(&ctx_handle);-structetm_event_data*event_data=perf_get_aux(handle);+structetm_ctxt*ctxt=this_cpu_ptr(&etm_ctxt);+structperf_output_handle*handle=&ctxt->handle;+structetm_event_data*event_data;structlist_head*path;+/*+*Ifwestillhaveaccesstotheevent_dataviahandle,+*confirmthatwehaven'tmessedupthetracking.+*/+if(handle->event&&+WARN_ON(perf_get_aux(handle)!=ctxt->event_data))+return;++event_data=ctxt->event_data;+/* Clear the event_data as this ETM is stopping the trace. */+ctxt->event_data=NULL;+if(event->hw.state==PERF_HES_STOPPED)return;+/* We must have a valid event_data for a running event */+if(WARN_ON(!event_data))+return;+if(!csdev)return;
@@ -460,7 +503,13 @@ static void etm_event_stop(struct perf_event *event, int mode)/* tell the core */event->hw.state=PERF_HES_STOPPED;-if(mode&PERF_EF_UPDATE){+/*+*Ifthehandleisnotboundtoaneventanymore+*(e.g,thesinkdriverwasunabletorestartthe+*handleduetolackofbufferspace),wedon't+*havetodoanythinghere.+*/+if(handle->event&&(mode&PERF_EF_UPDATE)){if(WARN_ON_ONCE(handle->event!=event))return;
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:33
Document the device tree bindings for Embedded Trace Extensions.
ETE can be connected to legacy coresight components and thus
could optionally contain a connection graph as described by
the CoreSight bindings.
Cc: devicetree@vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since v4:
- Fix the out-ports definition (Rob Herring)
---
.../devicetree/bindings/arm/ete.yaml | 75 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
@@ -0,0 +1,75 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+# Copyright 2021, Arm Ltd+%YAML1.2+---+$id:"http://devicetree.org/schemas/arm/ete.yaml#"+$schema:"http://devicetree.org/meta-schemas/core.yaml#"++title:ARM Embedded Trace Extensions++maintainers:+-Suzuki K Poulose <suzuki.poulose@arm.com>+-Mathieu Poirier <mathieu.poirier@linaro.org>++description:|+Arm Embedded Trace Extension(ETE) is a per CPU trace component that+allows tracing the CPU execution. It overlaps with the CoreSight ETMv4+architecture and has extended support for future architecture changes.+The trace generated by the ETE could be stored via legacy CoreSight+components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer+Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to+legacy CoreSight components, a node must be listed per instance, along+with any optional connection graph as per the coresight bindings.+See bindings/arm/coresight.txt.++properties:+$nodename:+pattern:"^ete([0-9a-f]+)$"+compatible:+items:+-const:arm,embedded-trace-extension++cpu:+description:|+Handle to the cpu this ETE is bound to.+$ref:/schemas/types.yaml#/definitions/phandle++out-ports:+description:|+Output connections from the ETE to legacy CoreSight trace bus.+$ref:/schemas/graph.yaml#/properties/ports+properties:+port:+description:Output connection from the ETE to legacy CoreSight Trace bus.+$ref:/schemas/graph.yaml#/properties/port++required:+-compatible+-cpu++additionalProperties:false++examples:++# An ETE node without legacy CoreSight connections+-|+ete0 {+compatible = "arm,embedded-trace-extension";+cpu = <&cpu_0>;+};+# An ETE node with legacy CoreSight connections+-|+ete1 {+compatible = "arm,embedded-trace-extension";+cpu = <&cpu_1>;++out-ports { /* legacy coresight connection */+port {+ete1_out_port:endpoint {+remote-endpoint = <&funnel_in_port0>;+};+};+};+};++...
From: Rob Herring <robh@kernel.org> Date: 2021-03-23 22:47:00
On Tue, 23 Mar 2021 12:06:41 +0000, Suzuki K Poulose wrote:
Document the device tree bindings for Embedded Trace Extensions.
ETE can be connected to legacy coresight components and thus
could optionally contain a connection graph as described by
the CoreSight bindings.
Cc: devicetree@vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since v4:
- Fix the out-ports definition (Rob Herring)
---
.../devicetree/bindings/arm/ete.yaml | 75 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:08:34
Add ETE as one of the supported device types we support
with ETM4x driver. The devices are named following the
existing convention as ete<N>.
ETE mandates that the trace resource status register is programmed
before the tracing is turned on. For the moment simply write to
it indicating TraceActive.
ETE shares most of the registers with ETMv4 except for some and
also adds some new registers. Re-arrange the ETMv4x list
to share the common definitions and add the ETE sysreg support.
Reviewed-by: Mike Leach <redacted>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since v4:
- Make ete sysreg read/write static (kernel test robot)
- Squashed ETE sysreg support patch to this one.
- Write 0 to TRCSTATR
---
drivers/hwtracing/coresight/Kconfig | 10 +--
.../coresight/coresight-etm4x-core.c | 90 ++++++++++++++++---
.../coresight/coresight-etm4x-sysfs.c | 19 +++-
drivers/hwtracing/coresight/coresight-etm4x.h | 66 ++++++++++++--
4 files changed, 155 insertions(+), 30 deletions(-)
@@ -115,6 +115,38 @@ void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)}}+staticu64ete_sysreg_read(u32offset,bool_relaxed,bool_64bit)+{+u64res=0;++switch(offset){+ETE_READ_CASES(res)+default:+pr_warn_ratelimited("ete: trying to read unsupported register @%x\n",+offset);+}++if(!_relaxed)+__iormb(res);/* Imitate the !relaxed I/O helpers */++returnres;+}++staticvoidete_sysreg_write(u64val,u32offset,bool_relaxed,bool_64bit)+{+if(!_relaxed)+__iowmb();/* Imitate the !relaxed I/O helpers */+if(!_64bit)+val&=GENMASK(31,0);++switch(offset){+ETE_WRITE_CASES(val)+default:+pr_warn_ratelimited("ete: trying to write to unsupported register @%x\n",+offset);+}+}+staticvoidetm_detect_os_lock(structetmv4_drvdata*drvdata,structcsdev_access*csa){
@@ -401,6 +433,13 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)etm4x_relaxed_write32(csa,trcpdcr|TRCPDCR_PU,TRCPDCR);}+/*+*ETEmandatesthattheTRCRSRiswrittentobefore+*enablingit.+*/+if(etm4x_is_ete(drvdata))+etm4x_relaxed_write32(csa,TRCRSR_TA,TRCRSR);+/* Enable the trace unit */etm4x_relaxed_write32(csa,1,TRCPRGCTLR);
@@ -1855,6 +1903,22 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)fwnode_property_present(dev_fwnode(dev),"qcom,skip-power-up"))drvdata->skip_power_up=true;+major=ETM_ARCH_MAJOR_VERSION(drvdata->arch);+minor=ETM_ARCH_MINOR_VERSION(drvdata->arch);++if(etm4x_is_ete(drvdata)){+type_name="ete";+/* ETE v1 has major version == 0b101. Adjust this for logging.*/+major-=4;+}else{+type_name="etm";+}++desc.name=devm_kasprintf(dev,GFP_KERNEL,+"%s%d",type_name,drvdata->cpu);+if(!desc.name)+return-ENOMEM;+etm4_init_trace_id(drvdata);etm4_set_default(&drvdata->config);
@@ -160,10 +164,22 @@#define CASE_NOP(__unused, x) \case(x):/* fall through */+#define ETE_ONLY_SYSREG_LIST(op, val) \+CASE_##op((val),TRCRSR)\+CASE_##op((val),TRCEXTINSELRn(1))\+CASE_##op((val),TRCEXTINSELRn(2))\+CASE_##op((val),TRCEXTINSELRn(3))+/* List of registers accessible via System instructions */-#define ETM_SYSREG_LIST(op, val) \-CASE_##op((val),TRCPRGCTLR)\+#define ETM4x_ONLY_SYSREG_LIST(op, val) \CASE_##op((val),TRCPROCSELR)\+CASE_##op((val),TRCVDCTLR)\+CASE_##op((val),TRCVDSACCTLR)\+CASE_##op((val),TRCVDARCCTLR)\+CASE_##op((val),TRCOSLAR)++#define ETM_COMMON_SYSREG_LIST(op, val) \+CASE_##op((val),TRCPRGCTLR)\CASE_##op((val),TRCSTATR)\CASE_##op((val),TRCCONFIGR)\CASE_##op((val),TRCAUXCTLR)\
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:09:05
From: Anshuman Khandual <redacted>
Add support for dedicated sinks that are bound to individual CPUs. (e.g,
TRBE). To allow quicker access to the sink for a given CPU bound source,
keep a percpu array of the sink devices. Also, add support for building
a path to the CPU local sink from the ETM.
This adds a new percpu sink type CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM.
This new sink type is exclusively available and can only work with percpu
source type device CORESIGHT_DEV_SUBTYPE_SOURCE_PROC.
This defines a percpu structure that accommodates a single coresight_device
which can be used to store an initialized instance from a sink driver. As
these sinks are exclusively linked and dependent on corresponding percpu
sources devices, they should also be the default sink device during a perf
session.
Outwards device connections are scanned while establishing paths between a
source and a sink device. But such connections are not present for certain
percpu source and sink devices which are exclusively linked and dependent.
Build the path directly and skip connection scanning for such devices.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Mike Leach <redacted>
Signed-off-by: Anshuman Khandual <redacted>
[Moved the set/get percpu sink APIs from TRBE patch to here
Fixed build break on arm32
]
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since v4:
- Fix build on arm32 kernel
---
drivers/hwtracing/coresight/coresight-core.c | 29 ++++++++++++++++++--
drivers/hwtracing/coresight/coresight-priv.h | 3 ++
include/linux/coresight.h | 13 +++++++++
3 files changed, 43 insertions(+), 2 deletions(-)
@@ -784,6 +797,14 @@ static int _coresight_build_path(struct coresight_device *csdev,if(csdev==sink)gotoout;+if(coresight_is_percpu_source(csdev)&&coresight_is_percpu_sink(sink)&&+sink==per_cpu(csdev_sink,source_ops(csdev)->cpu_id(csdev))){+if(_coresight_build_path(sink,sink,path)==0){+found=true;+gotoout;+}+}+/* Not a sink - recursively explore each port found on this element */for(i=0;i<csdev->pdata->nr_outport;i++){structcoresight_device*child_dev;
@@ -999,8 +1020,12 @@ coresight_find_default_sink(struct coresight_device *csdev)intdepth=0;/* look for a default sink if we have not found for this device */-if(!csdev->def_sink)-csdev->def_sink=coresight_find_sink(csdev,&depth);+if(!csdev->def_sink){+if(coresight_is_percpu_source(csdev))+csdev->def_sink=per_cpu(csdev_sink,source_ops(csdev)->cpu_id(csdev));+if(!csdev->def_sink)+csdev->def_sink=coresight_find_sink(csdev,&depth);+}returncsdev->def_sink;}
@@ -0,0 +1,14 @@+What: /sys/bus/coresight/devices/trbe<cpu>/align+Date: March 2021+KernelVersion: 5.13+Contact: Anshuman Khandual <anshuman.khandual@arm.com>+Description: (Read) Shows the TRBE write pointer alignment. This value+ is fetched from the TRBIDR register.++What: /sys/bus/coresight/devices/trbe<cpu>/flag+Date: March 2021+KernelVersion: 5.13+Contact: Anshuman Khandual <anshuman.khandual@arm.com>+Description: (Read) Shows if TRBE updates in the memory are with access+ and dirty flag updates as well. This value is fetched from+ the TRBIDR register.
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -0,0 +1,38 @@+.. SPDX-License-Identifier: GPL-2.0++==============================+Trace Buffer Extension (TRBE).+==============================++:Author: Anshuman Khandual <anshuman.khandual@arm.com>+:Date: November 2020++Hardware Description+--------------------++Trace Buffer Extension (TRBE) is a percpu hardware which captures in system+memory, CPU traces generated from a corresponding percpu tracing unit. This+gets plugged in as a coresight sink device because the corresponding trace+generators (ETE), are plugged in as source device.++The TRBE is not compliant to CoreSight architecture specifications, but is+driven via the CoreSight driver framework to support the ETE (which is+CoreSight compliant) integration.++Sysfs files and directories+---------------------------++The TRBE devices appear on the existing coresight bus alongside the other+coresight devices::++ >$ ls /sys/bus/coresight/devices+ trbe0 trbe1 trbe2 trbe3++The ``trbe<N>`` named TRBEs are associated with a CPU.::++ >$ ls /sys/bus/coresight/devices/trbe0/+ align flag++*Key file items are:-*+*``align``: TRBE write pointer alignment+*``flag``: TRBE updates memory with access and dirty flags
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -0,0 +1,49 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+# Copyright 2021, Arm Ltd+%YAML1.2+---+$id:"http://devicetree.org/schemas/arm/trbe.yaml#"+$schema:"http://devicetree.org/meta-schemas/core.yaml#"++title:ARM Trace Buffer Extensions++maintainers:+-Anshuman Khandual <anshuman.khandual@arm.com>++description:|+Arm Trace Buffer Extension (TRBE) is a per CPU component+for storing trace generated on the CPU to memory. It is+accessed via CPU system registers. The software can verify+if it is permitted to use the component by checking the+TRBIDR register.++properties:+$nodename:+const:"trbe"+compatible:+items:+-const:arm,trace-buffer-extension++interrupts:+description:|+Exactly 1 PPI must be listed. For heterogeneous systems where+TRBE is only supported on a subset of the CPUs, please consult+the arm,gic-v3 binding for details on describing a PPI partition.+maxItems:1++required:+-compatible+-interrupts++additionalProperties:false++examples:++-|+#include <dt-bindings/interrupt-controller/arm-gic.h>++trbe {+compatible = "arm,trace-buffer-extension";+interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;+};+...
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2021-03-23 12:09:05
From: Anshuman Khandual <redacted>
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 <redacted>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
[ Mark the buffer truncated on WRAP event, error code cleanup ]
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since v4:
- Mark the buffer as truncated on WRAP event (Mike Leach)
- Tidy up limit_pointer computation from TRBLIMITR_EL1
- Fix error code for vmap failure. (Mathieu)
---
drivers/hwtracing/coresight/Kconfig | 14 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-trbe.c | 1157 ++++++++++++++++++
drivers/hwtracing/coresight/coresight-trbe.h | 152 +++
4 files changed, 1324 insertions(+)
create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
@@ -0,0 +1,1157 @@+// SPDX-License-Identifier: GPL-2.0+/*+*ThisdriverenablesTraceBufferExtension(TRBE)asaper-cpucoresight+*sinkdevicecouldthenpairwithanappropriateper-cpucoresightsource+*device(ETE)thusgeneratingrequiredtracedata.Tracecanbeenabled+*viatheperfframework.+*+*TheAUXbufferhandlingisinspiredfromArmSPEPMUdriver.+*+*Copyright(C)2020ARMLtd.+*+*Author:AnshumanKhandual<anshuman.khandual@arm.com>+*/+#define DRVNAME "arm_trbe"++#define pr_fmt(fmt) DRVNAME ": " fmt++#include<asm/barrier.h>+#include"coresight-trbe.h"++#define PERF_IDX2OFF(idx, buf) ((idx) % ((buf)->nr_pages << PAGE_SHIFT))++/*+*Apaddingpacketthatwillhelptheuserspacetools+*inskippingrelevantsectionsinthecapturedtrace+*datawhichcouldnotbedecoded.TRBEdoesn'tsupport+*formattingthetracedata,unlikethelegacyCoreSight+*sinksandthusweuseETEtracepacketstopadthe+*sectionsofthebuffer.+*/+#define ETE_IGNORE_PACKET 0x70++/*+*Minimumamountofmeaningfultracewillcontain:+*A-Sync,TraceInfo,TraceOn,Address,Atom.+*Thisisabout44bytesofETEtrace.Tobeon+*thesaferside,weassume64bytesistheminimum+*spacerequiredforameaningfulsession,before+*wehita"WRAP"event.+*/+#define TRBE_TRACE_MIN_BUF_SIZE 64++enumtrbe_fault_action{+TRBE_FAULT_ACT_WRAP,+TRBE_FAULT_ACT_SPURIOUS,+TRBE_FAULT_ACT_FATAL,+};++structtrbe_buf{+/*+*Eventhoughtrbe_baserepresentsvmap()+*mappedallocatedbuffer'sstartaddress,+*it'sbeingasunsignedlongforvarious+*arithmeticandcomparisionoperations&+*alsotobeconsistentwithtrbe_write&+*trbe_limitsiblingpointers.+*/+unsignedlongtrbe_base;+unsignedlongtrbe_limit;+unsignedlongtrbe_write;+intnr_pages;+void**pages;+boolsnapshot;+structtrbe_cpudata*cpudata;+};++structtrbe_cpudata{+booltrbe_flag;+u64trbe_align;+intcpu;+enumcs_modemode;+structtrbe_buf*buf;+structtrbe_drvdata*drvdata;+};++structtrbe_drvdata{+structtrbe_cpudata__percpu*cpudata;+structperf_output_handle__percpu**handle;+structhlist_nodehotplug_node;+intirq;+cpumask_tsupported_cpus;+enumcpuhp_statetrbe_online;+structplatform_device*pdev;+};++staticinttrbe_alloc_node(structperf_event*event)+{+if(event->cpu==-1)+returnNUMA_NO_NODE;+returncpu_to_node(event->cpu);+}++staticvoidtrbe_drain_buffer(void)+{+tsb_csync();+dsb(nsh);+}++staticvoidtrbe_drain_and_disable_local(void)+{+u64trblimitr=read_sysreg_s(SYS_TRBLIMITR_EL1);++trbe_drain_buffer();++/*+*DisabletheTRBEwithoutclearingLIMITPTRwhich+*mightberequiredforfetchingthebufferlimits.+*/+trblimitr&=~TRBLIMITR_ENABLE;+write_sysreg_s(trblimitr,SYS_TRBLIMITR_EL1);+isb();+}++staticvoidtrbe_reset_local(void)+{+trbe_drain_and_disable_local();+write_sysreg_s(0,SYS_TRBLIMITR_EL1);+write_sysreg_s(0,SYS_TRBPTR_EL1);+write_sysreg_s(0,SYS_TRBBASER_EL1);+write_sysreg_s(0,SYS_TRBSR_EL1);+}++staticvoidtrbe_stop_and_truncate_event(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);++/*+*Wecannotproceedwiththebuffercollectionandwe+*donothaveanydataforthecurrentsession.The+*etm_perfdriverexpectstocloseouttheaux_buffer+*atevent_stop().SodisabletheTRBEhereandleave+*theupdate_buffer()toreturna0size.+*/+trbe_drain_and_disable_local();+perf_aux_output_flag(handle,PERF_AUX_FLAG_TRUNCATED);+*this_cpu_ptr(buf->cpudata->drvdata->handle)=NULL;+}++/*+*TRBEBufferManagement+*+*TheTRBEbufferspansfromthebasepointertillthelimitpointer.Whenenabled,+*itstartswritingtracedatafromthewritepointeronwardtillthelimitpointer.+*Whenthewritepointerreachestheaddressjustbeforethelimitpointer,itgets+*wrappedaroundagaintothebasepointer.ThisiscalledaTRBEwrapevent,which+*generatesamaintenanceinterruptwhenoperatedinWRAPorFILLmode.Thisdriver+*usesFILLmode,wheretheTRBEstopsthetracecollectionatwrapevent.TheIRQ+*handlerupdatestheAUXbufferandre-enablestheTRBEwithupdatedWRITEand+*LIMITpointers.+*+*WraparoundwithanIRQ+*------<------<-------<-----<-----+*||+*------>------>------->----->-----+*+*+---------------+-----------------------++*|||+*+---------------+-----------------------++*BasePointerWritePointerLimitPointer+*+*ThebaseandlimitpointersalwaysneedstobePAGE_SIZEaligned.Butthewrite+*pointercanbealignedtotheimplementationdefinedTRBEtracebufferalignment+*ascapturedintrbe_cpudata->trbe_align.+*+*+*headtailwakeup+*+---------------------------------------+-----~~------+*|$$$$$$$|################|$$$$$$$$$$$$$$||+*+---------------------------------------+-----~~------+*BasePointerWritePointerLimitPointer+*+*Theperf_output_handleindices(head,tail,wakeup)aremonotonicallyincreasing+*valueswhichtracksallthedriverwritesanduserreadsfromtheperfauxiliary+*buffer.Generally[head..tail]istheareawherethedrivercanwriteintounless+*thewakeupisbehindthetail.EnabledTRBEbufferspanneedstobeadjustedand+*configureddependingontheperf_output_handleindices,sothatthedriverdoes+*notoverrideintoareasintheperfauxiliarybufferwhichisbeingoryettobe+*consumedfromtheuserspace.TheenabledTRBEbufferareaisamovingsubsetof+*theallocatedperfauxiliarybuffer.+*/+staticvoidtrbe_pad_buf(structperf_output_handle*handle,intlen)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);+u64head=PERF_IDX2OFF(handle->head,buf);++memset((void*)buf->trbe_base+head,ETE_IGNORE_PACKET,len);+if(!buf->snapshot)+perf_aux_output_skip(handle,len);+}++staticunsignedlongtrbe_snapshot_offset(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);++/*+*TheETEtracehasalignmentsynchronizationpacketsallowing+*thedecodertoresetincaseofanoverfloworcorruption.+*Sowecanusetheentirebufferforthesnapshotmode.+*/+returnbuf->nr_pages*PAGE_SIZE;+}++/*+*TRBELimitCalculation+*+*ThefollowingmarkersareusedtoillustratevariousTRBEbuffersituations.+*+*$$$$-Dataarea,unconsumedcapturedtracedata,nottobeoverridden+*####-Freearea,enabled,tracewillbewritten+*%%%%-Freearea,disabled,tracewillnotbewritten+*====-Freearea,paddedwithETE_IGNORE_PACKET,tracewillbeskipped+*/+staticunsignedlong__trbe_normal_offset(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);+structtrbe_cpudata*cpudata=buf->cpudata;+constu64bufsize=buf->nr_pages*PAGE_SIZE;+u64limit=bufsize;+u64head,tail,wakeup;++head=PERF_IDX2OFF(handle->head,buf);++/*+*head+*------->|+*|+*headTRBEaligntail+*+----|-------|---------------|-------++*|$$$$|=======|###############|$$$$$$$|+*+----|-------|---------------|-------++*trbe_basetrbe_base+nr_pages+*+*Perfauxbufferoutputheadpositioncanbemisaligneddependingon+*variousfactorsincludinguserspacereads.Incasemisaligned,head+*needstobealignedbeforeTRBEcanbeconfigured.Padthealignment+*gapwithETE_IGNORE_PACKETbytesthatwillbeignoredbyusertools+*andskipthissectionthusadvancingthehead.+*/+if(!IS_ALIGNED(head,cpudata->trbe_align)){+unsignedlongdelta=roundup(head,cpudata->trbe_align)-head;++delta=min(delta,handle->size);+trbe_pad_buf(handle,delta);+head=PERF_IDX2OFF(handle->head,buf);+}++/*+*head=tail(size=0)+*+----|-------------------------------++*|$$$$|$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$|+*+----|-------------------------------++*trbe_basetrbe_base+nr_pages+*+*Perfauxbufferdoesnothaveanyspaceforthedrivertowriteinto.+*Justcommunicatetracetruncationeventtotheuserspacebymarking+*itwithPERF_AUX_FLAG_TRUNCATED.+*/+if(!handle->size){+perf_aux_output_flag(handle,PERF_AUX_FLAG_TRUNCATED);+return0;+}++/* Compute the tail and wakeup indices now that we've aligned head */+tail=PERF_IDX2OFF(handle->head+handle->size,buf);+wakeup=PERF_IDX2OFF(handle->wakeup,buf);++/*+*LetscalculatethebufferareawhichTRBEcouldwriteinto.There+*arethreepossiblescenarioshere.Limitneedstobealignedwith+*PAGE_SIZEpertheTRBErequirement.Alwaysavoidclobberingthe+*unconsumeddata.+*+*1)head<tail+*+*headtail+*+----|-----------------------|-------++*|$$$$|#######################|$$$$$$$|+*+----|-----------------------|-------++*trbe_baselimittrbe_base+nr_pages+*+*TRBEcouldwriteinto[head..tail]area.Unlessthetailisrightat+*theendofthebuffer,neitheranwraparoundnoranIRQisexpected+*whilebeingenabled.+*+*2)head==tail+*+*head=tail(size>0)+*+----|-------------------------------++*|%%%%|###############################|+*+----|-------------------------------++*trbe_baselimit=trbe_base+nr_pages+*+*TRBEshouldjustwriteinto[head..base+nr_pages]areaeventhough+*theentirebufferisempty.Reasonbeing,whenthetracereachesthe+*endofthebuffer,itwilljustwraparoundwithanIRQgivingan+*opportunitytoreconfigurethebuffer.+*+*3)tail<head+*+*tailhead+*+----|-----------------------|-------++*|%%%%|$$$$$$$$$$$$$$$$$$$$$$$|#######|+*+----|-----------------------|-------++*trbe_baselimit=trbe_base+nr_pages+*+*TRBEshouldjustwriteinto[head..base+nr_pages]areaeventhough+*the[trbe_base..tail]isalsoempty.Reasonbeing,whenthetrace+*reachestheendofthebuffer,itwilljustwraparoundwithanIRQ+*givinganopportunitytoreconfigurethebuffer.+*/+if(head<tail)+limit=round_down(tail,PAGE_SIZE);++/*+*Wakeupmaybearbitrarilyfarintothefuture.Ifit'snotinthe+*currentgeneration,eitherwe'llwrapbeforehittingit,orit's+*inthepastandhasbeenhandledalready.+*+*Ifthere'sawakeupbeforewewrap,arrangetobewokenupbythe+*pageboundaryfollowingit.Keepthetailboundaryifthat'slower.+*+*headwakeuptail+*+----|---------------|-------|-------++*|$$$$|###############|%%%%%%%|$$$$$$$|+*+----|---------------|-------|-------++*trbe_baselimittrbe_base+nr_pages+*/+if(handle->wakeup<(handle->head+handle->size)&&head<=wakeup)+limit=min(limit,round_up(wakeup,PAGE_SIZE));++/*+*Therearetwosituationwhenthiscanhappeni.elimitisbefore+*theheadandhenceTRBEcannotbeconfigured.+*+*1)head<tail(aligneddownwithPAGE_SIZE)andalsotheyareboth+*withinthesamePAGEsizerange.+*+*PAGE_SIZE+*|----------------------|+*+*limitheadtail+*+------------|------|--------|-------++*|$$$$$$$$$$$$$$$$$$$|========|$$$$$$$|+*+------------|------|--------|-------++*trbe_basetrbe_base+nr_pages+*+*2)head<wakeup(alignedupwithPAGE_SIZE)<tailandalsoboth+*headandwakeuparewithinsamePAGEsizerange.+*+*PAGE_SIZE+*|----------------------|+*+*limitheadwakeuptail+*+----|------|-------|--------|-------++*|$$$$$$$$$$$|=======|========|$$$$$$$|+*+----|------|-------|--------|-------++*trbe_basetrbe_base+nr_pages+*/+if(limit>head)+returnlimit;++trbe_pad_buf(handle,handle->size);+perf_aux_output_flag(handle,PERF_AUX_FLAG_TRUNCATED);+return0;+}++staticunsignedlongtrbe_normal_offset(structperf_output_handle*handle)+{+structtrbe_buf*buf=perf_get_aux(handle);+u64limit=__trbe_normal_offset(handle);+u64head=PERF_IDX2OFF(handle->head,buf);++/*+*Iftheheadistooclosetothelimitandwedon't+*havespaceforameaningfulrun,weratherpadit+*andstartfresh.+*/+if(limit&&(limit-head<TRBE_TRACE_MIN_BUF_SIZE)){+trbe_pad_buf(handle,limit-head);+limit=__trbe_normal_offset(handle);+}+returnlimit;+}++staticunsignedlongcompute_trbe_buffer_limit(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);+unsignedlongoffset;++if(buf->snapshot)+offset=trbe_snapshot_offset(handle);+else+offset=trbe_normal_offset(handle);+returnbuf->trbe_base+offset;+}++staticvoidclr_trbe_status(void)+{+u64trbsr=read_sysreg_s(SYS_TRBSR_EL1);++WARN_ON(is_trbe_enabled());+trbsr&=~TRBSR_IRQ;+trbsr&=~TRBSR_TRG;+trbsr&=~TRBSR_WRAP;+trbsr&=~(TRBSR_EC_MASK<<TRBSR_EC_SHIFT);+trbsr&=~(TRBSR_BSC_MASK<<TRBSR_BSC_SHIFT);+trbsr&=~TRBSR_STOP;+write_sysreg_s(trbsr,SYS_TRBSR_EL1);+}++staticvoidset_trbe_limit_pointer_enabled(unsignedlongaddr)+{+u64trblimitr=read_sysreg_s(SYS_TRBLIMITR_EL1);++WARN_ON(!IS_ALIGNED(addr,(1UL<<TRBLIMITR_LIMIT_SHIFT)));+WARN_ON(!IS_ALIGNED(addr,PAGE_SIZE));++trblimitr&=~TRBLIMITR_NVM;+trblimitr&=~(TRBLIMITR_FILL_MODE_MASK<<TRBLIMITR_FILL_MODE_SHIFT);+trblimitr&=~(TRBLIMITR_TRIG_MODE_MASK<<TRBLIMITR_TRIG_MODE_SHIFT);+trblimitr&=~(TRBLIMITR_LIMIT_MASK<<TRBLIMITR_LIMIT_SHIFT);++/*+*Filltracebuffermodeisusedherewhileconfiguringthe+*TRBEfortracecapture.Inthisparticularmode,thetrace+*collectionisstoppedandamaintenanceinterruptisraised+*whenthecurrentwritepointerwraps.Thispauseintrace+*collectiongivesthesoftwareanopportunitytocapturethe+*tracedataintheinterrupthandler,beforereconfiguring+*theTRBE.+*/+trblimitr|=(TRBE_FILL_MODE_FILL&TRBLIMITR_FILL_MODE_MASK)<<TRBLIMITR_FILL_MODE_SHIFT;++/*+*TriggermodeisnotusedherewhileconfiguringtheTRBEfor+*thetracecapture.Hencejustkeepthisintheignoremode.+*/+trblimitr|=(TRBE_TRIG_MODE_IGNORE&TRBLIMITR_TRIG_MODE_MASK)<<+TRBLIMITR_TRIG_MODE_SHIFT;+trblimitr|=(addr&PAGE_MASK);++trblimitr|=TRBLIMITR_ENABLE;+write_sysreg_s(trblimitr,SYS_TRBLIMITR_EL1);++/* Synchronize the TRBE enable event */+isb();+}++staticvoidtrbe_enable_hw(structtrbe_buf*buf)+{+WARN_ON(buf->trbe_write<buf->trbe_base);+WARN_ON(buf->trbe_write>=buf->trbe_limit);+set_trbe_disabled();+isb();+clr_trbe_status();+set_trbe_base_pointer(buf->trbe_base);+set_trbe_write_pointer(buf->trbe_write);++/*+*Synchronizealltheregisterupdates+*tillnowbeforeenablingtheTRBE.+*/+isb();+set_trbe_limit_pointer_enabled(buf->trbe_limit);+}++staticenumtrbe_fault_actiontrbe_get_fault_act(u64trbsr)+{+intec=get_trbe_ec(trbsr);+intbsc=get_trbe_bsc(trbsr);++WARN_ON(is_trbe_running(trbsr));+if(is_trbe_trg(trbsr)||is_trbe_abort(trbsr))+returnTRBE_FAULT_ACT_FATAL;++if((ec==TRBE_EC_STAGE1_ABORT)||(ec==TRBE_EC_STAGE2_ABORT))+returnTRBE_FAULT_ACT_FATAL;++if(is_trbe_wrap(trbsr)&&(ec==TRBE_EC_OTHERS)&&(bsc==TRBE_BSC_FILLED)){+if(get_trbe_write_pointer()==get_trbe_base_pointer())+returnTRBE_FAULT_ACT_WRAP;+}+returnTRBE_FAULT_ACT_SPURIOUS;+}++staticvoid*arm_trbe_alloc_buffer(structcoresight_device*csdev,+structperf_event*event,void**pages,+intnr_pages,boolsnapshot)+{+structtrbe_buf*buf;+structpage**pglist;+inti;++/*+*TRBELIMITandTRBEWRITEpointersmustbepagealigned.Butwith+*justasinglepage,therewouldnotbeanyroomleftwhilewriting+*intoapartiallyfilledTRBEbufferafterthepagesizealignment.+*Hencerestricttheminimumbuffersizeastwopages.+*/+if(nr_pages<2)+returnNULL;++buf=kzalloc_node(sizeof(*buf),GFP_KERNEL,trbe_alloc_node(event));+if(!buf)+returnERR_PTR(-ENOMEM);++pglist=kcalloc(nr_pages,sizeof(*pglist),GFP_KERNEL);+if(!pglist){+kfree(buf);+returnERR_PTR(-ENOMEM);+}++for(i=0;i<nr_pages;i++)+pglist[i]=virt_to_page(pages[i]);++buf->trbe_base=(unsignedlong)vmap(pglist,nr_pages,VM_MAP,PAGE_KERNEL);+if(!buf->trbe_base){+kfree(pglist);+kfree(buf);+returnERR_PTR(-ENOMEM);+}+buf->trbe_limit=buf->trbe_base+nr_pages*PAGE_SIZE;+buf->trbe_write=buf->trbe_base;+buf->snapshot=snapshot;+buf->nr_pages=nr_pages;+buf->pages=pages;+kfree(pglist);+returnbuf;+}++staticvoidarm_trbe_free_buffer(void*config)+{+structtrbe_buf*buf=config;++vunmap((void*)buf->trbe_base);+kfree(buf);+}++staticunsignedlongarm_trbe_update_buffer(structcoresight_device*csdev,+structperf_output_handle*handle,+void*config)+{+structtrbe_drvdata*drvdata=dev_get_drvdata(csdev->dev.parent);+structtrbe_cpudata*cpudata=dev_get_drvdata(&csdev->dev);+structtrbe_buf*buf=config;+enumtrbe_fault_actionact;+unsignedlongsize,offset;+unsignedlongwrite,base,status;+unsignedlongflags;++WARN_ON(buf->cpudata!=cpudata);+WARN_ON(cpudata->cpu!=smp_processor_id());+WARN_ON(cpudata->drvdata!=drvdata);+if(cpudata->mode!=CS_MODE_PERF)+return0;++perf_aux_output_flag(handle,PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW);++/*+*WeareabouttodisabletheTRBE.Andthiscouldinturn+*fillupthebuffertriggering,anIRQ.Thiscouldbeconsumed+*bythePEasynchronously,causingaracehereagainst+*theIRQhandlerinclosingoutthehandle.So,letus+*makesuretheIRQcan'ttriggerwhilewearecollecting+*thebuffer.WealsomakesurethataWRAPeventishandled+*accordingly.+*/+local_irq_save(flags);++/*+*IftheTRBEwasdisabledduetolackofspaceintheAUXbufferora+*spuriousfault,thedriverleavesitdisabled,truncatingthebuffer.+*Sincetheetm_perfdriverexpectstocloseouttheAUXbuffer,the+*driverskipsit.Thus,justpassin0sizeheretoindicatethatthe+*bufferwastruncated.+*/+if(!is_trbe_enabled()){+size=0;+gotodone;+}+/*+*perfhandlestructureneedstobesharedwiththeTRBEIRQhandlerfor+*capturingtracedataandrestartingthehandle.Thereisaprobability+*ofanundefinedreferencebasedcrashwhenetmeventisbeingstopped+*whileaTRBEIRQalsogettingprocessed.Thishappensduetherelease+*ofperfhandleviaperf_aux_output_end()inetm_event_stop().Stopping+*theTRBEherewillensurethatnoIRQcouldbegeneratedwhentheperf+*handlegetsfreedinetm_event_stop().+*/+trbe_drain_and_disable_local();+write=get_trbe_write_pointer();+base=get_trbe_base_pointer();++/* Check if there is a pending interrupt and handle it here */+status=read_sysreg_s(SYS_TRBSR_EL1);+if(is_trbe_irq(status)){++/*+*NowthatwearehandlingtheIRQhere,cleartheIRQ+*fromthestatus,tolettheirqhandlerknowthatit+*istakencareof.+*/+clr_trbe_irq();+isb();++act=trbe_get_fault_act(status);+/*+*IfthiswasnotduetoaWRAPevent,wehavesome+*errorsandassuchbufferisempty.+*/+if(act!=TRBE_FAULT_ACT_WRAP){+size=0;+gotodone;+}++/*+*Otherwise,thebufferisfullandthewritepointer+*hasreachedbase.AdjustthisbacktotheLimitpointer+*forcorrectsize.Also,markthebuffertruncated.+*/+write=get_trbe_limit_pointer();+perf_aux_output_flag(handle,PERF_AUX_FLAG_TRUNCATED);+}++offset=write-base;+if(WARN_ON_ONCE(offset<PERF_IDX2OFF(handle->head,buf)))+size=0;+else+size=offset-PERF_IDX2OFF(handle->head,buf);++done:+local_irq_restore(flags);++if(buf->snapshot)+handle->head+=size;+returnsize;+}++staticintarm_trbe_enable(structcoresight_device*csdev,u32mode,void*data)+{+structtrbe_drvdata*drvdata=dev_get_drvdata(csdev->dev.parent);+structtrbe_cpudata*cpudata=dev_get_drvdata(&csdev->dev);+structperf_output_handle*handle=data;+structtrbe_buf*buf=etm_perf_sink_config(handle);++WARN_ON(cpudata->cpu!=smp_processor_id());+WARN_ON(cpudata->drvdata!=drvdata);+if(mode!=CS_MODE_PERF)+return-EINVAL;++*this_cpu_ptr(drvdata->handle)=handle;+cpudata->buf=buf;+cpudata->mode=mode;+buf->cpudata=cpudata;+buf->trbe_limit=compute_trbe_buffer_limit(handle);+buf->trbe_write=buf->trbe_base+PERF_IDX2OFF(handle->head,buf);+if(buf->trbe_limit==buf->trbe_base){+trbe_stop_and_truncate_event(handle);+return0;+}+trbe_enable_hw(buf);+return0;+}++staticintarm_trbe_disable(structcoresight_device*csdev)+{+structtrbe_drvdata*drvdata=dev_get_drvdata(csdev->dev.parent);+structtrbe_cpudata*cpudata=dev_get_drvdata(&csdev->dev);+structtrbe_buf*buf=cpudata->buf;++WARN_ON(buf->cpudata!=cpudata);+WARN_ON(cpudata->cpu!=smp_processor_id());+WARN_ON(cpudata->drvdata!=drvdata);+if(cpudata->mode!=CS_MODE_PERF)+return-EINVAL;++trbe_drain_and_disable_local();+buf->cpudata=NULL;+cpudata->buf=NULL;+cpudata->mode=CS_MODE_DISABLED;+return0;+}++staticvoidtrbe_handle_spurious(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);++buf->trbe_limit=compute_trbe_buffer_limit(handle);+buf->trbe_write=buf->trbe_base+PERF_IDX2OFF(handle->head,buf);+if(buf->trbe_limit==buf->trbe_base){+trbe_drain_and_disable_local();+return;+}+trbe_enable_hw(buf);+}++staticvoidtrbe_handle_overflow(structperf_output_handle*handle)+{+structperf_event*event=handle->event;+structtrbe_buf*buf=etm_perf_sink_config(handle);+unsignedlongoffset,size;+structetm_event_data*event_data;++offset=get_trbe_limit_pointer()-get_trbe_base_pointer();+size=offset-PERF_IDX2OFF(handle->head,buf);+if(buf->snapshot)+handle->head+=size;++/*+*Markthebufferastruncated,aswehavestoppedthetrace+*collectionupontheWRAPevent,withoutstoppingthesource.+*/+perf_aux_output_flag(handle,PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW|+PERF_AUX_FLAG_TRUNCATED);+perf_aux_output_end(handle,size);+event_data=perf_aux_output_begin(handle,event);+if(!event_data){+/*+*Weareunabletorestartthetracecollection,+*thusleavetheTRBEdisabled.Theetm-perfdriver+*isabletodetectthiswithadisconnectedhandle+*(handle->event=NULL).+*/+trbe_drain_and_disable_local();+*this_cpu_ptr(buf->cpudata->drvdata->handle)=NULL;+return;+}+buf->trbe_limit=compute_trbe_buffer_limit(handle);+buf->trbe_write=buf->trbe_base+PERF_IDX2OFF(handle->head,buf);+if(buf->trbe_limit==buf->trbe_base){+trbe_stop_and_truncate_event(handle);+return;+}+*this_cpu_ptr(buf->cpudata->drvdata->handle)=handle;+trbe_enable_hw(buf);+}++staticboolis_perf_trbe(structperf_output_handle*handle)+{+structtrbe_buf*buf=etm_perf_sink_config(handle);+structtrbe_cpudata*cpudata=buf->cpudata;+structtrbe_drvdata*drvdata=cpudata->drvdata;+intcpu=smp_processor_id();++WARN_ON(buf->trbe_base!=get_trbe_base_pointer());+WARN_ON(buf->trbe_limit!=get_trbe_limit_pointer());++if(cpudata->mode!=CS_MODE_PERF)+returnfalse;++if(cpudata->cpu!=cpu)+returnfalse;++if(!cpumask_test_cpu(cpu,&drvdata->supported_cpus))+returnfalse;++returntrue;+}++staticirqreturn_tarm_trbe_irq_handler(intirq,void*dev)+{+structperf_output_handle**handle_ptr=dev;+structperf_output_handle*handle=*handle_ptr;+enumtrbe_fault_actionact;+u64status;++/*+*EnsurethetraceisvisibletotheCPUsand+*anyexternalabortshavebeenresolved.+*/+trbe_drain_and_disable_local();++status=read_sysreg_s(SYS_TRBSR_EL1);+/*+*IfthependingIRQwashandledbyupdate_buffercallback+*wehavenothingtodohere.+*/+if(!is_trbe_irq(status))+returnIRQ_NONE;++clr_trbe_irq();+isb();++if(WARN_ON_ONCE(!handle)||!perf_get_aux(handle))+returnIRQ_NONE;++if(!is_perf_trbe(handle))+returnIRQ_NONE;++/*+*Ensureperfcallbackshavecompleted,whichmaydisable+*thetracebufferinresponsetoaTRUNCATIONflag.+*/+irq_work_run();++act=trbe_get_fault_act(status);+switch(act){+caseTRBE_FAULT_ACT_WRAP:+trbe_handle_overflow(handle);+break;+caseTRBE_FAULT_ACT_SPURIOUS:+trbe_handle_spurious(handle);+break;+caseTRBE_FAULT_ACT_FATAL:+trbe_stop_and_truncate_event(handle);+break;+}+returnIRQ_HANDLED;+}++staticconststructcoresight_ops_sinkarm_trbe_sink_ops={+.enable=arm_trbe_enable,+.disable=arm_trbe_disable,+.alloc_buffer=arm_trbe_alloc_buffer,+.free_buffer=arm_trbe_free_buffer,+.update_buffer=arm_trbe_update_buffer,+};++staticconststructcoresight_opsarm_trbe_cs_ops={+.sink_ops=&arm_trbe_sink_ops,+};++staticssize_talign_show(structdevice*dev,structdevice_attribute*attr,char*buf)+{+structtrbe_cpudata*cpudata=dev_get_drvdata(dev);++returnsprintf(buf,"%llx\n",cpudata->trbe_align);+}+staticDEVICE_ATTR_RO(align);++staticssize_tflag_show(structdevice*dev,structdevice_attribute*attr,char*buf)+{+structtrbe_cpudata*cpudata=dev_get_drvdata(dev);++returnsprintf(buf,"%d\n",cpudata->trbe_flag);+}+staticDEVICE_ATTR_RO(flag);++staticstructattribute*arm_trbe_attrs[]={+&dev_attr_align.attr,+&dev_attr_flag.attr,+NULL,+};++staticconststructattribute_grouparm_trbe_group={+.attrs=arm_trbe_attrs,+};++staticconststructattribute_group*arm_trbe_groups[]={+&arm_trbe_group,+NULL,+};++staticvoidarm_trbe_enable_cpu(void*info)+{+structtrbe_drvdata*drvdata=info;++trbe_reset_local();+enable_percpu_irq(drvdata->irq,IRQ_TYPE_NONE);+}++staticvoidarm_trbe_register_coresight_cpu(structtrbe_drvdata*drvdata,intcpu)+{+structtrbe_cpudata*cpudata=per_cpu_ptr(drvdata->cpudata,cpu);+structcoresight_device*trbe_csdev=coresight_get_percpu_sink(cpu);+structcoresight_descdesc={0};+structdevice*dev;++if(WARN_ON(trbe_csdev))+return;++dev=&cpudata->drvdata->pdev->dev;+desc.name=devm_kasprintf(dev,GFP_KERNEL,"trbe%d",cpu);+if(IS_ERR(desc.name))+gotocpu_clear;++desc.type=CORESIGHT_DEV_TYPE_SINK;+desc.subtype.sink_subtype=CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM;+desc.ops=&arm_trbe_cs_ops;+desc.pdata=dev_get_platdata(dev);+desc.groups=arm_trbe_groups;+desc.dev=dev;+trbe_csdev=coresight_register(&desc);+if(IS_ERR(trbe_csdev))+gotocpu_clear;++dev_set_drvdata(&trbe_csdev->dev,cpudata);+coresight_set_percpu_sink(cpu,trbe_csdev);+return;+cpu_clear:+cpumask_clear_cpu(cpu,&drvdata->supported_cpus);+}++staticvoidarm_trbe_probe_cpu(void*info)+{+structtrbe_drvdata*drvdata=info;+intcpu=smp_processor_id();+structtrbe_cpudata*cpudata=per_cpu_ptr(drvdata->cpudata,cpu);+u64trbidr;++if(WARN_ON(!cpudata))+gotocpu_clear;++if(!is_trbe_available()){+pr_err("TRBE is not implemented on cpu %d\n",cpu);+gotocpu_clear;+}++trbidr=read_sysreg_s(SYS_TRBIDR_EL1);+if(!is_trbe_programmable(trbidr)){+pr_err("TRBE is owned in higher exception level on cpu %d\n",cpu);+gotocpu_clear;+}++cpudata->trbe_align=1ULL<<get_trbe_address_align(trbidr);+if(cpudata->trbe_align>SZ_2K){+pr_err("Unsupported alignment on cpu %d\n",cpu);+gotocpu_clear;+}+cpudata->trbe_flag=get_trbe_flag_update(trbidr);+cpudata->cpu=cpu;+cpudata->drvdata=drvdata;+return;+cpu_clear:+cpumask_clear_cpu(cpu,&drvdata->supported_cpus);+}++staticvoidarm_trbe_remove_coresight_cpu(void*info)+{+intcpu=smp_processor_id();+structtrbe_drvdata*drvdata=info;+structtrbe_cpudata*cpudata=per_cpu_ptr(drvdata->cpudata,cpu);+structcoresight_device*trbe_csdev=coresight_get_percpu_sink(cpu);++disable_percpu_irq(drvdata->irq);+trbe_reset_local();+if(trbe_csdev){+coresight_unregister(trbe_csdev);+cpudata->drvdata=NULL;+coresight_set_percpu_sink(cpu,NULL);+}+}++staticintarm_trbe_probe_coresight(structtrbe_drvdata*drvdata)+{+intcpu;++drvdata->cpudata=alloc_percpu(typeof(*drvdata->cpudata));+if(!drvdata->cpudata)+return-ENOMEM;++for_each_cpu(cpu,&drvdata->supported_cpus){+smp_call_function_single(cpu,arm_trbe_probe_cpu,drvdata,1);+if(cpumask_test_cpu(cpu,&drvdata->supported_cpus))+arm_trbe_register_coresight_cpu(drvdata,cpu);+if(cpumask_test_cpu(cpu,&drvdata->supported_cpus))+smp_call_function_single(cpu,arm_trbe_enable_cpu,drvdata,1);+}+return0;+}++staticintarm_trbe_remove_coresight(structtrbe_drvdata*drvdata)+{+intcpu;++for_each_cpu(cpu,&drvdata->supported_cpus)+smp_call_function_single(cpu,arm_trbe_remove_coresight_cpu,drvdata,1);+free_percpu(drvdata->cpudata);+return0;+}++staticintarm_trbe_cpu_startup(unsignedintcpu,structhlist_node*node)+{+structtrbe_drvdata*drvdata=hlist_entry_safe(node,structtrbe_drvdata,hotplug_node);++if(cpumask_test_cpu(cpu,&drvdata->supported_cpus)){++/*+*IfthisCPUwasnotprobedforTRBE,+*initializeitnow.+*/+if(!coresight_get_percpu_sink(cpu)){+arm_trbe_probe_cpu(drvdata);+if(cpumask_test_cpu(cpu,&drvdata->supported_cpus))+arm_trbe_register_coresight_cpu(drvdata,cpu);+if(cpumask_test_cpu(cpu,&drvdata->supported_cpus))+arm_trbe_enable_cpu(drvdata);+}else{+arm_trbe_enable_cpu(drvdata);+}+}+return0;+}++staticintarm_trbe_cpu_teardown(unsignedintcpu,structhlist_node*node)+{+structtrbe_drvdata*drvdata=hlist_entry_safe(node,structtrbe_drvdata,hotplug_node);++if(cpumask_test_cpu(cpu,&drvdata->supported_cpus)){+disable_percpu_irq(drvdata->irq);+trbe_reset_local();+}+return0;+}++staticintarm_trbe_probe_cpuhp(structtrbe_drvdata*drvdata)+{+enumcpuhp_statetrbe_online;+intret;++trbe_online=cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,DRVNAME,+arm_trbe_cpu_startup,arm_trbe_cpu_teardown);+if(trbe_online<0)+returntrbe_online;++ret=cpuhp_state_add_instance(trbe_online,&drvdata->hotplug_node);+if(ret){+cpuhp_remove_multi_state(trbe_online);+returnret;+}+drvdata->trbe_online=trbe_online;+return0;+}++staticvoidarm_trbe_remove_cpuhp(structtrbe_drvdata*drvdata)+{+cpuhp_remove_multi_state(drvdata->trbe_online);+}++staticintarm_trbe_probe_irq(structplatform_device*pdev,+structtrbe_drvdata*drvdata)+{+intret;++drvdata->irq=platform_get_irq(pdev,0);+if(drvdata->irq<0){+pr_err("IRQ not found for the platform device\n");+returndrvdata->irq;+}++if(!irq_is_percpu(drvdata->irq)){+pr_err("IRQ is not a PPI\n");+return-EINVAL;+}++if(irq_get_percpu_devid_partition(drvdata->irq,&drvdata->supported_cpus))+return-EINVAL;++drvdata->handle=alloc_percpu(typeof(*drvdata->handle));+if(!drvdata->handle)+return-ENOMEM;++ret=request_percpu_irq(drvdata->irq,arm_trbe_irq_handler,DRVNAME,drvdata->handle);+if(ret){+free_percpu(drvdata->handle);+returnret;+}+return0;+}++staticvoidarm_trbe_remove_irq(structtrbe_drvdata*drvdata)+{+free_percpu_irq(drvdata->irq,drvdata->handle);+free_percpu(drvdata->handle);+}++staticintarm_trbe_device_probe(structplatform_device*pdev)+{+structcoresight_platform_data*pdata;+structtrbe_drvdata*drvdata;+structdevice*dev=&pdev->dev;+intret;++drvdata=devm_kzalloc(dev,sizeof(*drvdata),GFP_KERNEL);+if(!drvdata)+return-ENOMEM;++pdata=coresight_get_platform_data(dev);+if(IS_ERR(pdata))+returnPTR_ERR(pdata);++dev_set_drvdata(dev,drvdata);+dev->platform_data=pdata;+drvdata->pdev=pdev;+ret=arm_trbe_probe_irq(pdev,drvdata);+if(ret)+returnret;++ret=arm_trbe_probe_coresight(drvdata);+if(ret)+gotoprobe_failed;++ret=arm_trbe_probe_cpuhp(drvdata);+if(ret)+gotocpuhp_failed;++return0;+cpuhp_failed:+arm_trbe_remove_coresight(drvdata);+probe_failed:+arm_trbe_remove_irq(drvdata);+returnret;+}++staticintarm_trbe_device_remove(structplatform_device*pdev)+{+structtrbe_drvdata*drvdata=platform_get_drvdata(pdev);++arm_trbe_remove_cpuhp(drvdata);+arm_trbe_remove_coresight(drvdata);+arm_trbe_remove_irq(drvdata);+return0;+}++staticconststructof_device_idarm_trbe_of_match[]={+{.compatible="arm,trace-buffer-extension"},+{},+};+MODULE_DEVICE_TABLE(of,arm_trbe_of_match);++staticstructplatform_driverarm_trbe_driver={+.driver={+.name=DRVNAME,+.of_match_table=of_match_ptr(arm_trbe_of_match),+.suppress_bind_attrs=true,+},+.probe=arm_trbe_device_probe,+.remove=arm_trbe_device_remove,+};++staticint__initarm_trbe_init(void)+{+intret;++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)+return0;++pr_err("Error registering %s platform driver\n",DRVNAME);+returnret;+}++staticvoid__exitarm_trbe_exit(void)+{+platform_driver_unregister(&arm_trbe_driver);+}+module_init(arm_trbe_init);+module_exit(arm_trbe_exit);++MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual@arm.com>");+MODULE_DESCRIPTION("Arm Trace Buffer Extension (TRBE) driver");+MODULE_LICENSE("GPL v2");