To whom it may concern:
I am an attorney writing on behalf of Arm. It has come to Arm’s attention that one or more emails originating from this email address have claimed to offer a database of personal information of Arm DevSummit attendees. Please be advised that Arm strongly believes that such solicitations are unauthorized and may constitute violations of one or more state and/or federal laws.
In addition, the use of Arm’s federally registered trademark for CoreSight (U.S. Trademark No. 4930183) as a portion of an email address offering to sell confidential information regarding Arm DevSummit attendees is likely to cause confusion regarding the source of your offer. The use of a registered trademark in a manner that is likely to cause confusion or to deceive is a violation of 15 U.S.C. § 1114, and a trademark registrant may recover damages, including costs and attorneys’ fees, under 15 U.S.C. § 1117.
If you contend that you are an authorized custodian of this information and that your e‐mail solicitations are lawful, please provide an explanation. Otherwise, Arm hereby demands that you and any affiliates cease and desist any and all solicitations purporting to offer to sell the personal information of Arm DevSummit attendees. In addition, Arm hereby demands that you and any affiliates cease any use of the CoreSight registered trademark in any manner which falsely suggests a connection between you and Arm or that is likely to cause confusion.
Please be advised that Arm intends to explore additional appropriate means to cease this activity, including alerting the U.S. Federal Trade Commission and the Office of the Attorney General of California.
Regards,
-mjf
Michael J. Forbes
mforbes(a)reedsmith.com<mailto:mforbes@reedsmith.com>
Reed Smith LLP
Suite 1700
811 Main Street
Houston, TX 77002-6110
Direct 713.469.3864
Fax 713.469.3899
* * *
This E-mail, along with any attachments, is considered confidential and may well be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Thank you for your cooperation.
Disclaimer Version RS.US.201.407.01
CoreSight ETMv4.4 introduced system instructions for accessing
the ETM. This also implies that they may not be on the amba bus.
Right now all the CoreSight components are accessed via memory
map. Also, we have some common routines in coresight generic
code driver (e.g, CS_LOCK, claim/disclaim), which assume the
mmio. In order to preserve the generic algorithms at a single
place and to allow dynamic switch for ETMs, this series introduces
an abstraction layer for accessing a coresight device. It is
designed such that the mmio access are fast tracked (i.e, without
an indirect function call).
This will also help us to get rid of the driver+attribute specific
sysfs show/store routines and replace them with a single routine
to access a given register offset (which can be embedded in the
dev_ext_attribute). This is not currently implemented in the series,
but can be achieved.
Further we switch the generic routines to work with the abstraction.
With this in place, we refactor the etm4x code a bit to allow for
supporting the system instructions with very little new code. The
changes also switch to using the system instructions by default
even when we may have an MMIO.
We use TRCDEVARCH for the detection of the ETM component, which
is a standard register as per CoreSight architecture, rather than
the etm specific id register TRCIDR3. This is for making sure
that we are able to detect the ETM via system instructions accurately,
when the the trace unit could be anything (etm or a custom trace unit).
The series has been mildly tested on a model. I would really
appreciate any testing on real hardware.
Applies on coresight/next
Changes since V1:
- Flip the switch for iomem from no_iomem to io_mem in csdev_access.
- Split patches for claim/disclaim and CS_LOCK/UNLOCK conversions.
- Move device access initialisation for etm4x to the target CPU
- Cleanup secure exception level mask handling.
- Switch to use TRCDEVARCH for ETM component discovery. This
is for making
- Check the availability of OS/Software Locks before using them.
Suzuki K Poulose (19):
coresight: Introduce device access abstraction
coresight: tpiu: Prepare for using coresight device access abstraction
coresight: Convert coresight_timeout to use access abstraction
coresight: Convert claim/disclaim operations to use access wrappers
coresight: Use device access layer for Software lock/unlock operations
coresight: etm4x: Always read the registers on the host CPU
coresight: etm4x: Convert all register accesses
coresight: etm4x: Add commentary on the registers
coresight: etm4x: Add sysreg access helpers
coresight: etm4x: Define DEVARCH register fields
coresight: etm4x: Check for OS and Software Lock
coresight: etm4x: Cleanup secure exception level masks
coresight: etm4x: Clean up exception level masks
coresight: etm4x: Detect access early on the target CPU
coresight: etm4x: Use TRCDEVARCH for component discovery
coresight: etm4x: Detect system instructions support
coresight: etm4x: Refactor probing routine
coresight: etm4x: Add support for sysreg only devices
dts: bindings: coresight: ETMv4.4 system register access only units
.../devicetree/bindings/arm/coresight.txt | 6 +-
drivers/hwtracing/coresight/coresight-catu.c | 24 +-
.../hwtracing/coresight/coresight-cpu-debug.c | 22 +-
.../hwtracing/coresight/coresight-cti-sysfs.c | 5 +-
drivers/hwtracing/coresight/coresight-cti.c | 34 +-
drivers/hwtracing/coresight/coresight-etb10.c | 29 +-
.../coresight/coresight-etm3x-sysfs.c | 10 +-
drivers/hwtracing/coresight/coresight-etm3x.c | 35 +-
.../coresight/coresight-etm4x-sysfs.c | 44 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 716 +++++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.h | 440 ++++++++++-
.../hwtracing/coresight/coresight-funnel.c | 22 +-
drivers/hwtracing/coresight/coresight-priv.h | 9 +-
.../coresight/coresight-replicator.c | 31 +-
drivers/hwtracing/coresight/coresight-stm.c | 50 +-
.../hwtracing/coresight/coresight-tmc-etf.c | 38 +-
.../hwtracing/coresight/coresight-tmc-etr.c | 20 +-
drivers/hwtracing/coresight/coresight-tmc.c | 16 +-
drivers/hwtracing/coresight/coresight-tpiu.c | 32 +-
drivers/hwtracing/coresight/coresight.c | 130 +++-
include/linux/coresight.h | 230 +++++-
21 files changed, 1449 insertions(+), 494 deletions(-)
--
2.24.1
This 2 patch series provides fixes to ETF null pointer dereference crash
and TRCVMIDCCTLR1 register save and restore fix.
Patch 1 is an RFC since I am not sure of the fix provided since it looks
more like a band-aid than the actual fix.
Changes in v2:
* Remove extra fixes tag (Suzuki)
Sai Prakash Ranjan (2):
coresight: tmc-etf: Fix NULL pointer dereference in
tmc_enable_etf_sink_perf()
coresight: etm4x: Fix save and restore of TRCVMIDCCTLR1 register
drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 ++--
drivers/hwtracing/coresight/coresight-tmc-etf.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
base-commit: e209e73bee253afe969410150248f0c300c13d84
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
From: Leo Yan <leo.yan(a)linaro.org>
[ Upstream commit c9f5baa136777b2c982f6f7a90c9da69a88be148 ]
When 'etm->instructions_sample_period' is less than
'tidq->period_instructions', the function cs_etm__sample() cannot handle
this case properly with its logic.
Let's see below flow as an example:
- If we set itrace option '--itrace=i4', then function cs_etm__sample()
has variables with initialized values:
tidq->period_instructions = 0
etm->instructions_sample_period = 4
- When the first packet is coming:
packet->instr_count = 10; the number of instructions executed in this
packet is 10, thus update period_instructions as below:
tidq->period_instructions = 0 + 10 = 10
instrs_over = 10 - 4 = 6
offset = 10 - 6 - 1 = 3
tidq->period_instructions = instrs_over = 6
- When the second packet is coming:
packet->instr_count = 10; in the second pass, assume 10 instructions
in the trace sample again:
tidq->period_instructions = 6 + 10 = 16
instrs_over = 16 - 4 = 12
offset = 10 - 12 - 1 = -3 -> the negative value
tidq->period_instructions = instrs_over = 12
So after handle these two packets, there have below issues:
The first issue is that cs_etm__instr_addr() returns the address within
the current trace sample of the instruction related to offset, so the
offset is supposed to be always unsigned value. But in fact, function
cs_etm__sample() might calculate a negative offset value (in handling
the second packet, the offset is -3) and pass to cs_etm__instr_addr()
with u64 type with a big positive integer.
The second issue is it only synthesizes 2 samples for sample period = 4.
In theory, every packet has 10 instructions so the two packets have
total 20 instructions, 20 instructions should generate 5 samples
(4 x 5 = 20). This is because cs_etm__sample() only calls once
cs_etm__synth_instruction_sample() to generate instruction sample per
range packet.
This patch fixes the logic in function cs_etm__sample(); the basic
idea for handling coming packet is:
- To synthesize the first instruction sample, it combines the left
instructions from the previous packet and the head of the new
packet; then generate continuous samples with sample period;
- At the tail of the new packet, if it has the rest instructions,
these instructions will be left for the sequential sample.
Suggested-by: Mike Leach <mike.leach(a)linaro.org>
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Reviewed-by: Mike Leach <mike.leach(a)linaro.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Walker <robert.walker(a)arm.com>
Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com>
Cc: coresight ml <coresight(a)lists.linaro.org>
Cc: linux-arm-kernel(a)lists.infradead.org
Link: http://lore.kernel.org/lkml/20200219021811.20067-4-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/perf/util/cs-etm.c | 87 ++++++++++++++++++++++++++++++++--------
1 file changed, 70 insertions(+), 17 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 38298cbb07524..451eee24165ee 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1359,9 +1359,12 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
struct cs_etm_auxtrace *etm = etmq->etm;
int ret;
u8 trace_chan_id = tidq->trace_chan_id;
- u64 instrs_executed = tidq->packet->instr_count;
+ u64 instrs_prev;
- tidq->period_instructions += instrs_executed;
+ /* Get instructions remainder from previous packet */
+ instrs_prev = tidq->period_instructions;
+
+ tidq->period_instructions += tidq->packet->instr_count;
/*
* Record a branch when the last instruction in
@@ -1379,26 +1382,76 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
* TODO: allow period to be defined in cycles and clock time
*/
- /* Get number of instructions executed after the sample point */
- u64 instrs_over = tidq->period_instructions -
- etm->instructions_sample_period;
+ /*
+ * Below diagram demonstrates the instruction samples
+ * generation flows:
+ *
+ * Instrs Instrs Instrs Instrs
+ * Sample(n) Sample(n+1) Sample(n+2) Sample(n+3)
+ * | | | |
+ * V V V V
+ * --------------------------------------------------
+ * ^ ^
+ * | |
+ * Period Period
+ * instructions(Pi) instructions(Pi')
+ *
+ * | |
+ * \---------------- -----------------/
+ * V
+ * tidq->packet->instr_count
+ *
+ * Instrs Sample(n...) are the synthesised samples occurring
+ * every etm->instructions_sample_period instructions - as
+ * defined on the perf command line. Sample(n) is being the
+ * last sample before the current etm packet, n+1 to n+3
+ * samples are generated from the current etm packet.
+ *
+ * tidq->packet->instr_count represents the number of
+ * instructions in the current etm packet.
+ *
+ * Period instructions (Pi) contains the the number of
+ * instructions executed after the sample point(n) from the
+ * previous etm packet. This will always be less than
+ * etm->instructions_sample_period.
+ *
+ * When generate new samples, it combines with two parts
+ * instructions, one is the tail of the old packet and another
+ * is the head of the new coming packet, to generate
+ * sample(n+1); sample(n+2) and sample(n+3) consume the
+ * instructions with sample period. After sample(n+3), the rest
+ * instructions will be used by later packet and it is assigned
+ * to tidq->period_instructions for next round calculation.
+ */
/*
- * Calculate the address of the sampled instruction (-1 as
- * sample is reported as though instruction has just been
- * executed, but PC has not advanced to next instruction)
+ * Get the initial offset into the current packet instructions;
+ * entry conditions ensure that instrs_prev is less than
+ * etm->instructions_sample_period.
*/
- u64 offset = (instrs_executed - instrs_over - 1);
- u64 addr = cs_etm__instr_addr(etmq, trace_chan_id,
- tidq->packet, offset);
+ u64 offset = etm->instructions_sample_period - instrs_prev;
+ u64 addr;
- ret = cs_etm__synth_instruction_sample(
- etmq, tidq, addr, etm->instructions_sample_period);
- if (ret)
- return ret;
+ while (tidq->period_instructions >=
+ etm->instructions_sample_period) {
+ /*
+ * Calculate the address of the sampled instruction (-1
+ * as sample is reported as though instruction has just
+ * been executed, but PC has not advanced to next
+ * instruction)
+ */
+ addr = cs_etm__instr_addr(etmq, trace_chan_id,
+ tidq->packet, offset - 1);
+ ret = cs_etm__synth_instruction_sample(
+ etmq, tidq, addr,
+ etm->instructions_sample_period);
+ if (ret)
+ return ret;
- /* Carry remaining instructions into next sample period */
- tidq->period_instructions = instrs_over;
+ offset += etm->instructions_sample_period;
+ tidq->period_instructions -=
+ etm->instructions_sample_period;
+ }
}
if (etm->sample_branches) {
--
2.25.1
This 2 patch series provides fixes to ETF null pointer dereference crash
and TRCVMIDCCTLR1 register save and restore fix.
Patch 1 is an RFC since I am not sure of the fix provided since it looks
more like a band-aid than the actual fix.
Sai Prakash Ranjan (2):
coresight: tmc-etf: Fix NULL pointer dereference in
tmc_enable_etf_sink_perf()
coresight: etm4x: Fix save and restore of TRCVMIDCCTLR1 register
drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 ++--
drivers/hwtracing/coresight/coresight-tmc-etf.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
base-commit: e209e73bee253afe969410150248f0c300c13d84
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hello guys,
There was an issue reported where the ETM timestamp values would
freeze or be 0 sometimes when using perf mode of tracing. This was
observed only with perf mode and not sysfs but was reproducible
with both ETR and ETF as sinks.
After some debugging, I found that it's mostly to do with CPU
idle states. For perf mode, I never see entering CPU_PM_ENTER
or EXIT(since the check is mode) and so etm4_cpu_save() and
restore() are not called and I believe the contexts are not
properly saved and restored across low power states leading
to these bad timestamp values. For sysfs tracing, I see save
and restore called for respective ETMs when CPUs enter low
power states.
For testing, I would run perf record and report commands in a loop.
perf record -e cs_etm/@tmc_etf0/ -N -o perf.data -- some_test
perf report -D -i perf.data | grep Timestamp | head
On other shell, I would try to suspend the system:
echo freeze/mem > /sys/power/state
After waking up from suspend, perf commands would continue to
run and reports would continue to show either 0 or same
timestamps for some period of time.
Even the above test does not always reproduce the issue but
the observation that save and restore is not called is always
consistent with perf cs mode.
Any idea as to what might be missing for perf mode or if it is
expected or some limitation?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
Hi,
Just writing to check if you would be interested in acquiring the attendees
list of "Arm DevSummit" |Oct 06th - 08th |2020.
Each record will contain details like: Contact Name, Title, Phone Number,
Fax Number, Physical address, State/City, Company Name, Company URL, and
most importantly verified email addresses.
Let us know if you are interested and we will revert back with cost and
other deliverables.
Regards,
Laura Miller| Sales Team|
Email: laura(a)globaltradevisitors.com
"If you don't wish to receive email from us please reply back with Opt Out"