All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: "André Przywara" <andre.przywara@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Wei Li <liwei391@huawei.com>, James Clark <james.clark@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-kernel@vger.kernel.org, Al Grant <Al.Grant@arm.com>
Subject: Re: [PATCH v2 14/14] perf arm-spe: Add support for ARMv8.3-SPE
Date: Wed, 21 Oct 2020 18:17:48 +0800	[thread overview]
Message-ID: <20201021101748.GB3194@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <df1faa9b-d8cb-ebcf-b70f-3672a6d8db1f@arm.com>

On Wed, Oct 21, 2020 at 10:26:07AM +0100, André Przywara wrote:
> On 21/10/2020 06:10, Leo Yan wrote:
> 
> Hi,
> 
> > On Tue, Oct 20, 2020 at 10:54:44PM +0100, Andr� Przywara wrote:
> >> On 29/09/2020 14:39, Leo Yan wrote:
> >>
> >> Hi,
> >>
> >>> From: Wei Li <liwei391@huawei.com>
> >>>
> >>> This patch is to support Armv8.3 extension for SPE, it adds alignment
> >>> field in the Events packet and it supports the Scalable Vector Extension
> >>> (SVE) for Operation packet and Events packet with two additions:
> >>>
> >>>   - The vector length for SVE operations in the Operation Type packet;
> >>>   - The incomplete predicate and empty predicate fields in the Events
> >>>     packet.
> >>>
> >>> Signed-off-by: Wei Li <liwei391@huawei.com>
> >>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> >>> ---
> >>>  .../arm-spe-decoder/arm-spe-pkt-decoder.c     | 84 ++++++++++++++++++-
> >>>  .../arm-spe-decoder/arm-spe-pkt-decoder.h     |  6 ++
> >>>  2 files changed, 87 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >>> index 05a4c74399d7..3ec381fddfcb 100644
> >>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >>> @@ -342,14 +342,73 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >>>  					return ret;
> >>>  			}
> >>>  		}
> >>> +		if (idx > 2) {
> >>
> >> As I mentioned in the other patch, I doubt this extra comparison is
> >> useful. Does that protect us from anything?
> > 
> > It's the same reason with Event packet which have explained for replying
> > patch 10, the condition is to respect the SPE specifiction:
> > 
> >   E[11], byte 1, bit [11], when SZ == 0b10 , or SZ == 0b11
> >      Alignment.
> >      ...
> >      Otherwise this bit reads-as-zero.
> > 
> > So we gives higher priority for checking payload size than the Event
> > bit setting; if you have other thinking for this, please let me know.
> 
> Ah, thanks for pointing this out. It looks like a bug in the manual
> then, because I don't see why bit 11 should be any different from bits
> [10:8] and bits [15:12] in this respect. And in the diagrams above you
> clearly see bit 11 being shown even when SZ == 0b01.
> 
> I will try to follow this up here.

Thanks for following up!

> >>> +			if (payload & SPE_EVT_PKT_ALIGNMENT) {
> >>
> >> Mmh, but this is bit 11, right?
> > 
> > Yes.
> > 
> >> So would need to go into the (idx > 1)
> >> section (covering bits 8-15)? Another reason to ditch this comparison above.
> > 
> > As has explained in patch 10, idx is not the same thing with "sz"
> > field; "idx" stands for payload length in bytes, so:
> > 
> >   idx = 1 << sz
> > 
> > The spec defines the sz is 2 or 3, thus idx is 4 or 8; so this is why
> > here use the condition "(idx > 2)".
> > 
> > I think here need to refine code for more explict expression so can
> > avoid confusion.  So I think it's better to condition such like:
> > 
> >   if (payload_len >= 4) {
> 
> Yes, that would be (or have been) more helpful, but as mentioned in the
> other patch, I'd rather see those comparisons go entirely.

Agree.  Will remove comparisons in next version.

Thanks,
Leo

  reply	other threads:[~2020-10-21 10:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 13:39 [PATCH v2 00/14] perf arm-spe: Refactor decoding & dumping flow Leo Yan
2020-09-29 13:39 ` [PATCH v2 01/14] perf arm-spe: Include bitops.h for BIT() macro Leo Yan
2020-10-08 13:44   ` André Przywara
2020-09-29 13:39 ` [PATCH v2 02/14] perf arm-spe: Fix a typo in comment Leo Yan
2020-10-08 13:44   ` André Przywara
2020-09-29 13:39 ` [PATCH v2 03/14] perf arm-spe: Refactor payload length calculation Leo Yan
2020-10-08 13:44   ` André Przywara
2020-10-12  0:21     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 04/14] perf arm-spe: Fix packet length handling Leo Yan
2020-10-08 13:45   ` André Przywara
2020-09-29 13:39 ` [PATCH v2 05/14] perf arm-spe: Refactor printing string to buffer Leo Yan
2020-10-08 13:46   ` André Przywara
2020-10-12  0:29     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 06/14] perf arm-spe: Refactor packet header parsing Leo Yan
2020-10-08 19:49   ` André Przywara
2020-10-12  1:00     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 07/14] perf arm-spe: Refactor address packet handling Leo Yan
2020-10-19  9:01   ` André Przywara
2020-10-19 10:41     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 08/14] perf arm-spe: Refactor context " Leo Yan
2020-10-20 21:53   ` André Przywara
2020-09-29 13:39 ` [PATCH v2 09/14] perf arm-spe: Refactor counter " Leo Yan
2020-10-20 21:53   ` André Przywara
2020-10-21  3:52     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 10/14] perf arm-spe: Refactor event type handling Leo Yan
2020-10-20 21:54   ` André Przywara
2020-10-21  4:54     ` Leo Yan
2020-10-21  9:20       ` André Przywara
2020-10-21 10:13         ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 11/14] perf arm-spe: Refactor operation packet handling Leo Yan
2020-09-29 13:39 ` [PATCH v2 12/14] perf arm-spe: Add more sub classes for operation packet Leo Yan
2020-10-20 21:54   ` André Przywara
2020-10-21  5:16     ` Leo Yan
2020-09-29 13:39 ` [PATCH v2 13/14] perf arm_spe: Decode memory tagging properties Leo Yan
2020-09-29 13:39 ` [PATCH v2 14/14] perf arm-spe: Add support for ARMv8.3-SPE Leo Yan
2020-10-20 21:54   ` André Przywara
2020-10-21  5:10     ` Leo Yan
2020-10-21  9:26       ` André Przywara
2020-10-21 10:17         ` Leo Yan [this message]
2020-10-21 14:53           ` André Przywara
2020-10-22  0:44             ` Leo Yan
2020-10-13 14:53 ` [PATCH v2 00/14] perf arm-spe: Refactor decoding & dumping flow Arnaldo Carvalho de Melo
2020-10-13 15:19   ` Leo Yan

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20201021101748.GB3194@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=Al.Grant@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andre.przywara@arm.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.