From: James Clark <james.clark@arm.com> To: Anshuman Khandual <anshuman.khandual@arm.com>, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, peterz@infradead.org, acme@kernel.org Cc: suzuki.poulose@arm.com, 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>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V2 4/8] perf: Capture branch privilege information Date: Thu, 10 Mar 2022 10:21:03 +0000 [thread overview] Message-ID: <6dc9a4e5-8f74-dfb5-d9f6-60e9d6b65146@arm.com> (raw) In-Reply-To: <20220309033642.144769-5-anshuman.khandual@arm.com> On 09/03/2022 03:36, Anshuman Khandual wrote: > Platforms like arm64 could capture privilege level information for all the > branch records. Hence this adds a new element in the struct branch_entry to > record the privilege level information, which could be requested through a > new event.attr.branch_sample_type based flag PERF_SAMPLE_BRANCH_PRIV_SAVE. > This flag helps user choose whether privilege information is captured. > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Arnaldo Carvalho de Melo <acme@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> > Cc: Jiri Olsa <jolsa@redhat.com> > Cc: Namhyung Kim <namhyung@kernel.org> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Will Deacon <will@kernel.org> > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-perf-users@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> > --- > include/uapi/linux/perf_event.h | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index d29280adc3c4..0e96e2017f68 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -204,6 +204,8 @@ enum perf_branch_sample_type_shift { > > PERF_SAMPLE_BRANCH_HW_INDEX_SHIFT = 17, /* save low level index of raw branch records */ > > + PERF_SAMPLE_BRANCH_PRIV_SAVE_SHIFT = 18, /* save privillege mode */ > + > PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */ > }; > > @@ -233,6 +235,8 @@ enum perf_branch_sample_type { > > PERF_SAMPLE_BRANCH_HW_INDEX = 1U << PERF_SAMPLE_BRANCH_HW_INDEX_SHIFT, > > + PERF_SAMPLE_BRANCH_PRIV_SAVE = 1U << PERF_SAMPLE_BRANCH_PRIV_SAVE_SHIFT, > + > PERF_SAMPLE_BRANCH_MAX = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT, > }; > > @@ -271,6 +275,12 @@ enum { > PERF_BR_NEW_MAX, > }; > > +enum { > + PERF_BR_USER = 0, > + PERF_BR_KERNEL = 1, > + PERF_BR_HV = 2, > +}; 0 should be "PERF_BR_PRIV_UNKNOWN" so userspace knows if it was not enabled otherwise it will look like all samples are PERF_BR_USER when actually priv type recording was just disabled. I think it's not even always possible to go backwards from a sample to work out what the event attributes were so this can be interpreted (taking all of perf script and every corner case into account). Starting at 0=UNKNOWN is consistent with the other fields and makes parsing it a whole lot easier. James > + > #define PERF_SAMPLE_BRANCH_PLM_ALL \ > (PERF_SAMPLE_BRANCH_USER|\ > PERF_SAMPLE_BRANCH_KERNEL|\ > @@ -1386,7 +1396,8 @@ struct perf_branch_entry { > cycles:16, /* cycle count to last branch */ > type:4, /* branch type */ > new_type:4, /* additional branch type */ > - reserved:36; > + priv:2, /* privilege level */ > + reserved:34; > }; > > union perf_sample_weight {
WARNING: multiple messages have this Message-ID (diff)
From: James Clark <james.clark@arm.com> To: Anshuman Khandual <anshuman.khandual@arm.com>, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, peterz@infradead.org, acme@kernel.org Cc: suzuki.poulose@arm.com, 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>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V2 4/8] perf: Capture branch privilege information Date: Thu, 10 Mar 2022 10:21:03 +0000 [thread overview] Message-ID: <6dc9a4e5-8f74-dfb5-d9f6-60e9d6b65146@arm.com> (raw) In-Reply-To: <20220309033642.144769-5-anshuman.khandual@arm.com> On 09/03/2022 03:36, Anshuman Khandual wrote: > Platforms like arm64 could capture privilege level information for all the > branch records. Hence this adds a new element in the struct branch_entry to > record the privilege level information, which could be requested through a > new event.attr.branch_sample_type based flag PERF_SAMPLE_BRANCH_PRIV_SAVE. > This flag helps user choose whether privilege information is captured. > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Arnaldo Carvalho de Melo <acme@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> > Cc: Jiri Olsa <jolsa@redhat.com> > Cc: Namhyung Kim <namhyung@kernel.org> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Will Deacon <will@kernel.org> > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-perf-users@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> > --- > include/uapi/linux/perf_event.h | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index d29280adc3c4..0e96e2017f68 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -204,6 +204,8 @@ enum perf_branch_sample_type_shift { > > PERF_SAMPLE_BRANCH_HW_INDEX_SHIFT = 17, /* save low level index of raw branch records */ > > + PERF_SAMPLE_BRANCH_PRIV_SAVE_SHIFT = 18, /* save privillege mode */ > + > PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */ > }; > > @@ -233,6 +235,8 @@ enum perf_branch_sample_type { > > PERF_SAMPLE_BRANCH_HW_INDEX = 1U << PERF_SAMPLE_BRANCH_HW_INDEX_SHIFT, > > + PERF_SAMPLE_BRANCH_PRIV_SAVE = 1U << PERF_SAMPLE_BRANCH_PRIV_SAVE_SHIFT, > + > PERF_SAMPLE_BRANCH_MAX = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT, > }; > > @@ -271,6 +275,12 @@ enum { > PERF_BR_NEW_MAX, > }; > > +enum { > + PERF_BR_USER = 0, > + PERF_BR_KERNEL = 1, > + PERF_BR_HV = 2, > +}; 0 should be "PERF_BR_PRIV_UNKNOWN" so userspace knows if it was not enabled otherwise it will look like all samples are PERF_BR_USER when actually priv type recording was just disabled. I think it's not even always possible to go backwards from a sample to work out what the event attributes were so this can be interpreted (taking all of perf script and every corner case into account). Starting at 0=UNKNOWN is consistent with the other fields and makes parsing it a whole lot easier. James > + > #define PERF_SAMPLE_BRANCH_PLM_ALL \ > (PERF_SAMPLE_BRANCH_USER|\ > PERF_SAMPLE_BRANCH_KERNEL|\ > @@ -1386,7 +1396,8 @@ struct perf_branch_entry { > cycles:16, /* cycle count to last branch */ > type:4, /* branch type */ > new_type:4, /* additional branch type */ > - reserved:36; > + priv:2, /* privilege level */ > + reserved:34; > }; > > union perf_sample_weight { _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-03-10 10:21 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-09 3:36 [PATCH V2 0/8] perf: Expand perf_branch_entry Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 1/8] perf: Add irq and exception return branch types Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 2/8] perf: Add system error and not in transaction " Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 3/8] perf: Extend branch type classification Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 4/8] perf: Capture branch privilege information Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-10 10:21 ` James Clark [this message] 2022-03-10 10:21 ` James Clark 2022-03-11 3:25 ` Anshuman Khandual 2022-03-11 3:25 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 5/8] perf/tools: Add irq and exception return branch types Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 6/8] perf/tools: Add system error and not in transaction " Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 7/8] perf/tools: Extend branch type classification Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual 2022-03-10 10:16 ` James Clark 2022-03-10 10:16 ` James Clark 2022-03-11 3:52 ` Anshuman Khandual 2022-03-11 3:52 ` Anshuman Khandual 2022-03-09 3:36 ` [PATCH V2 8/8] perf/tools: Add branch privilege information request flag Anshuman Khandual 2022-03-09 3:36 ` Anshuman Khandual
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=6dc9a4e5-8f74-dfb5-d9f6-60e9d6b65146@arm.com \ --to=james.clark@arm.com \ --cc=acme@kernel.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=anshuman.khandual@arm.com \ --cc=jolsa@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-perf-users@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=peterz@infradead.org \ --cc=suzuki.poulose@arm.com \ --cc=tglx@linutronix.de \ --cc=will@kernel.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: linkBe 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.