Hi Russell,
On Mon, Aug 23, 2021 at 02:39:18PM +0100, Russell King (Oracle) wrote:
> On Mon, Aug 23, 2021 at 09:30:43PM +0800, Leo Yan wrote:
> > On Mon, Aug 23, 2021 at 01:23:42PM +0100, James Clark wrote:
[...]
> > > For x86, it's possible to include tools/include/asm/atomic.h, but that doesn't
> > > include arch/arm/include/asm/atomic.h and there are some other #ifdefs that might
> > > make it not so easy for Arm. Just wondering if you considered trying to include the
> > > existing one? Or decided that it was easier to duplicate it?
> >
> > Good finding!
> >
> > With you reminding, I recognized that the atomic operations for
> > arm/arm64 should be improved for user space program. So far, perf tool
> > simply uses the compiler's atomic implementations (from
> > asm-generic/atomic-gcc.h) for arm/arm64; but for a more reliable
> > implementation, I think we should improve the user space program with
> > architecture's atomic instructions.
>
> No we should not. Sometimes, what's in the kernel is for the kernel's
> use only, and not for userspace's use. That may be because what works
> in kernel space does not work in userspace.
>
> For example, the ARMv6+ atomic operations can be executed in userspace
> _provided_ they are only used on memory which has an exclusive monitor.
> They can't be used on anything that is not "normal memory".
Okay, IIUC, the requirement for "normal memory" and exclusive monitor
should also apply on aarch64 for ldrex/strex, Load-Acquire and
Store-Release instructions, etc. Otherwise, it's heavily dependent on
the exclusive monitors outside the cache coherency domain (but this is
out of the scopes for CPU).
perf tool is very likely to map memory with "normal memory" but we
cannot say it's always true.
So I agree there have risk for exporting the aarch32/aarch64 atomic
headers to user space.
> Prior to
> ARMv6, the atomic operations rely on disabling interrupts. That
> facility is simply not available to userspace, so these must not be
> made available to userspace.
>
> The same applies to bitops.
>
> We've been here before in the past, when the kernel headers were not
> separated from the user ABI headers, and people would write programs
> that included e.g. bitops.h on x86 because they had optimised bitops
> code. This made the userspace programs very non-portable - without
> re-implementing userspace versions of this stuff in every userspace
> program that did this stuff.
>
> So no, having experienced the effects of this kind of thing in the
> past, the kernel should _not_ export architecture specific code in
> header files to userspace.
>
> Also, it should be pointed out that by doing so, you create a licensing
> issue. If the code is GPLv2, and you build your program such that it
> incorporates GPLv2 code, then if the userspace program is not GPLv2
> compliant, you have a licensing problem, and in effect the program
> can be distributed.
>
> Please do not go down this route.
Thanks a lot for the suggestion and quick response.
Leo
Hi All,
The AXI write burst length is set to 0xF in TMC_AXICTL
register in the TMC ETR driver.
Definition in coresight-tmc.h
#define TMC_AXICTL_WR_BURST_16 0xF00
Marvell CN10K chip uses Coresight SoC-600 IP. Since write
burst length field is implementation defined, the maximum
value supported by our chip is 0x7.
We could not find a way to figure out the maximum supported
value through any of the ETR registers. So can you please
recommend a way to choose the value 0x7 without affecting
other silicons ?
With Regards,
Tanmay
Changes since v2:
Add Leo's reviewed by tag that I missed
James Clark (1):
perf cs-etm: Add warnings for missing DSOs
tools/perf/util/cs-etm.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.23.0
I'm submitting this as an RFC because there are a few changes I'd
like to get feedback on. The two changes I wanted to make were the
last two for Coresight warnings, but I ended up making some perf-wide
changes along the way.
For #1 (perf tools: Add WARN_ONCE equivalent for UI warnings)
* Does it make sense to add warn once equivalents at all, or
should the once be re-done for each usage?
* Or should there be some kind of generic 'once' wrapper?
For #3 (perf tools: Add disassembly warnings for annotate --stdio)
* If the output is interpreted by any other tools, then adding
these warnings could be an issue, so maybe this change could
be dropped, but no error output at all isn't ideal.
For #4 (perf tools: Add flag for tracking warnings of missing DSOs)
* In theory I could re-use 'annotate_warned', but it might make sense
to rename it in that case, or just leave the new auxtrace_warned and
remove any confusion.
This set applies to perf/core e73f0f0ee7541
Thanks
James
James Clark (6):
perf tools: Add WARN_ONCE equivalent for UI warnings
perf tools: Re-add annotate_warned functionality
perf tools: Add disassembly warnings for annotate --stdio
perf tools: Add flag for tracking warnings of missing DSOs
perf cs-etm: Improve Coresight zero timestamp warning
perf cs-etm: Add warnings for missing DSOs
tools/perf/ui/browsers/annotate.c | 1 +
tools/perf/ui/gtk/annotate.c | 1 +
tools/perf/util/annotate.c | 20 +++++++++++++++++--
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 7 +++++--
tools/perf/util/cs-etm.c | 10 +++++++++-
tools/perf/util/debug.h | 14 +++++++++++++
tools/perf/util/dso.h | 1 +
7 files changed, 49 insertions(+), 5 deletions(-)
--
2.28.0
Decoding ETE already works because it is a superset of
ETMv4, but if any new packet types are found then they will be
ignored by the decoder. This patchset creates an ETE decoder
which can output the new packets and saves a new register that
is required. No new packet types are handled by perf yet, as this
can be added in the future.
This set applies on top of "perf cs-etm: Support TRBE
(unformatted decoding)" on perf/core.
James Clark (6):
perf cs-etm: Refactor initialisation of decoder params.
perf cs-etm: Initialise architecture based on TRCIDR1
perf cs-etm: Save TRCDEVARCH register
perf cs-etm: Update OpenCSD decoder for ETE
perf cs-etm: Create ETE decoder
perf cs-etm: Print the decoder name
tools/build/feature/test-libopencsd.c | 4 +-
tools/perf/arch/arm/util/cs-etm.c | 13 +-
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 151 ++++++++----------
.../perf/util/cs-etm-decoder/cs-etm-decoder.h | 8 +
tools/perf/util/cs-etm.c | 54 ++++++-
tools/perf/util/cs-etm.h | 6 +-
6 files changed, 147 insertions(+), 89 deletions(-)
--
2.28.0
Changes since v1:
* Remove first 5 patches as they have been applied to perf/core
* Add Leo's kernel symbols suggestion and reviewed by tag
* Add reference to debuginfod as suggested by Arnaldo
Applies to perf/core f3c33cbd92
James Clark (1):
perf cs-etm: Add warnings for missing DSOs
tools/perf/util/cs-etm.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.23.0