All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Rajnesh Kanwal <rkanwal@rivosinc.com>
Cc: anshuman.khandual@arm.com, acme@kernel.org, broonie@kernel.org,
	catalin.marinas@arm.com, james.clark@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	mark.rutland@arm.com, mingo@redhat.com, peterz@infradead.org,
	robh@kernel.org, suzuki.poulose@arm.com, will@kernel.org,
	atishp@rivosinc.com
Subject: Re: [PATCH V13 - RESEND 09/10] arm64/perf: Implement branch records save on task sched out
Date: Wed, 02 Aug 2023 20:16:17 +0100	[thread overview]
Message-ID: <86il9x5k72.wl-maz@kernel.org> (raw)
In-Reply-To: <20230802115931.12212-1-rkanwal@rivosinc.com>

On Wed, 02 Aug 2023 12:59:31 +0100,
Rajnesh Kanwal <rkanwal@rivosinc.com> wrote:
> 
> >diff --git a/drivers/perf/arm_brbe.c b/drivers/perf/arm_brbe.c
> >index 203cd4f350d5..2177632befa6 100644
> >--- a/drivers/perf/arm_brbe.c
> >+++ b/drivers/perf/arm_brbe.c
> >@@ -165,6 +165,36 @@ static int stitch_stored_live_entries(struct brbe_regset *stored,
> > 	return min(nr_live + nr_stored, nr_max);
> > }
> > 
> >+static int brbe_branch_save(struct brbe_regset *live, int nr_hw_entries)
> >+{
> >+	u64 brbfcr = read_sysreg_s(SYS_BRBFCR_EL1);
> >+	int nr_live;
> >+
> >+	write_sysreg_s(brbfcr | BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> >+	isb();
> >+
> >+	nr_live = capture_brbe_regset(live, nr_hw_entries);
> >+
> >+	write_sysreg_s(brbfcr & ~BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> >+	isb();
> >+
> >+	return nr_live;
> >+}
> >+
> >+void armv8pmu_branch_save(struct arm_pmu *arm_pmu, void *ctx)
> >+{
> >+	struct arm64_perf_task_context *task_ctx = ctx;
> >+	struct brbe_regset live[BRBE_MAX_ENTRIES];
> >+	int nr_live, nr_store, nr_hw_entries;
> >+
> >+	nr_hw_entries = brbe_get_numrec(arm_pmu->reg_brbidr);
> >+	nr_live = brbe_branch_save(live, nr_hw_entries);
> >+	nr_store = task_ctx->nr_brbe_records;
> >+	nr_store = stitch_stored_live_entries(task_ctx->store, live, nr_store,
> >+					      nr_live, nr_hw_entries);
> >+	task_ctx->nr_brbe_records = nr_store;
> >+}
> 
> Asking out-of-curiosity. Have you thought about virtualization use
> case. Current LBR implementation create an event for the guest
> and save/restore happens using the sched_task callback. (Correct me
> if I am wrong). Given you are only saving and processing those saved
> entries, how do you plan to expose the entries to the guest?

Two possibilities:

- either we perform a full save/restore of the registers so that host
  and guest have isolated states

- or we trap all BRBE accesses and piggy-back on the perf framework
  for that, much like we already do for the PMU.

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Rajnesh Kanwal <rkanwal@rivosinc.com>
Cc: anshuman.khandual@arm.com, acme@kernel.org, broonie@kernel.org,
	catalin.marinas@arm.com, james.clark@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	mark.rutland@arm.com, mingo@redhat.com, peterz@infradead.org,
	robh@kernel.org, suzuki.poulose@arm.com, will@kernel.org,
	atishp@rivosinc.com
Subject: Re: [PATCH V13 - RESEND 09/10] arm64/perf: Implement branch records save on task sched out
Date: Wed, 02 Aug 2023 20:16:17 +0100	[thread overview]
Message-ID: <86il9x5k72.wl-maz@kernel.org> (raw)
In-Reply-To: <20230802115931.12212-1-rkanwal@rivosinc.com>

On Wed, 02 Aug 2023 12:59:31 +0100,
Rajnesh Kanwal <rkanwal@rivosinc.com> wrote:
> 
> >diff --git a/drivers/perf/arm_brbe.c b/drivers/perf/arm_brbe.c
> >index 203cd4f350d5..2177632befa6 100644
> >--- a/drivers/perf/arm_brbe.c
> >+++ b/drivers/perf/arm_brbe.c
> >@@ -165,6 +165,36 @@ static int stitch_stored_live_entries(struct brbe_regset *stored,
> > 	return min(nr_live + nr_stored, nr_max);
> > }
> > 
> >+static int brbe_branch_save(struct brbe_regset *live, int nr_hw_entries)
> >+{
> >+	u64 brbfcr = read_sysreg_s(SYS_BRBFCR_EL1);
> >+	int nr_live;
> >+
> >+	write_sysreg_s(brbfcr | BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> >+	isb();
> >+
> >+	nr_live = capture_brbe_regset(live, nr_hw_entries);
> >+
> >+	write_sysreg_s(brbfcr & ~BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> >+	isb();
> >+
> >+	return nr_live;
> >+}
> >+
> >+void armv8pmu_branch_save(struct arm_pmu *arm_pmu, void *ctx)
> >+{
> >+	struct arm64_perf_task_context *task_ctx = ctx;
> >+	struct brbe_regset live[BRBE_MAX_ENTRIES];
> >+	int nr_live, nr_store, nr_hw_entries;
> >+
> >+	nr_hw_entries = brbe_get_numrec(arm_pmu->reg_brbidr);
> >+	nr_live = brbe_branch_save(live, nr_hw_entries);
> >+	nr_store = task_ctx->nr_brbe_records;
> >+	nr_store = stitch_stored_live_entries(task_ctx->store, live, nr_store,
> >+					      nr_live, nr_hw_entries);
> >+	task_ctx->nr_brbe_records = nr_store;
> >+}
> 
> Asking out-of-curiosity. Have you thought about virtualization use
> case. Current LBR implementation create an event for the guest
> and save/restore happens using the sched_task callback. (Correct me
> if I am wrong). Given you are only saving and processing those saved
> entries, how do you plan to expose the entries to the guest?

Two possibilities:

- either we perform a full save/restore of the registers so that host
  and guest have isolated states

- or we trap all BRBE accesses and piggy-back on the perf framework
  for that, much like we already do for the PMU.

	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

  reply	other threads:[~2023-08-02 19:16 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11  8:24 [PATCH V13 - RESEND 00/10] arm64/perf: Enable branch stack sampling Anshuman Khandual
2023-07-11  8:24 ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 01/10] drivers: perf: arm_pmu: Add new sched_task() callback Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-08-10  5:05   ` Anshuman Khandual
2023-08-10  5:05     ` Anshuman Khandual
2023-08-10  9:41     ` Will Deacon
2023-08-10  9:41       ` Will Deacon
2023-08-10 11:49       ` Anshuman Khandual
2023-08-10 11:49         ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 02/10] arm64/perf: Add BRBE registers and fields Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-28 16:20   ` Will Deacon
2023-07-28 16:20     ` Will Deacon
2023-07-28 16:52     ` James Clark
2023-07-28 16:52       ` James Clark
2023-07-31  2:33       ` Anshuman Khandual
2023-07-31  2:33         ` Anshuman Khandual
2023-07-31  8:07         ` James Clark
2023-07-31  8:07           ` James Clark
2023-07-31  9:06         ` Mark Rutland
2023-07-31  9:06           ` Mark Rutland
2023-07-31 12:19           ` Anshuman Khandual
2023-07-31 12:19             ` Anshuman Khandual
2023-08-15 10:17           ` James Clark
2023-08-15 10:17             ` James Clark
2023-08-15 13:05             ` Mark Rutland
2023-08-15 13:05               ` Mark Rutland
2023-08-15 20:35               ` Peter Zijlstra
2023-08-15 20:35                 ` Peter Zijlstra
2023-07-11  8:24 ` [PATCH V13 - RESEND 03/10] arm64/perf: Add branch stack support in struct arm_pmu Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 04/10] arm64/perf: Add branch stack support in struct pmu_hw_events Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 05/10] arm64/perf: Add branch stack support in ARMV8 PMU Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 06/10] arm64/perf: Enable branch stack events via FEAT_BRBE Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11 19:26   ` Randy Dunlap
2023-07-11 19:26     ` Randy Dunlap
2023-07-12  2:42     ` Anshuman Khandual
2023-07-12  2:42       ` Anshuman Khandual
2023-07-25  7:12   ` Yang Shen
2023-07-25 11:42     ` Anshuman Khandual
2023-07-25 13:29       ` Suzuki K Poulose
2023-07-26  5:32         ` Anshuman Khandual
2023-08-02 12:40           ` Suzuki K Poulose
2023-08-02 12:40             ` Suzuki K Poulose
2023-08-03  2:39             ` Anshuman Khandual
2023-08-03  2:39               ` Anshuman Khandual
2023-07-26  6:26   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 07/10] arm64/perf: Add PERF_ATTACH_TASK_DATA to events with has_branch_stack() Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 08/10] arm64/perf: Add struct brbe_regset helper functions Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-11  8:24 ` [PATCH V13 - RESEND 09/10] arm64/perf: Implement branch records save on task sched out Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-08-02 11:59   ` Rajnesh Kanwal
2023-08-02 11:59     ` Rajnesh Kanwal
2023-08-02 19:16     ` Marc Zyngier [this message]
2023-08-02 19:16       ` Marc Zyngier
2023-07-11  8:24 ` [PATCH V13 - RESEND 10/10] arm64/perf: Implement branch records save on PMU IRQ Anshuman Khandual
2023-07-11  8:24   ` Anshuman Khandual
2023-07-31 13:05 ` [PATCH V13 - RESEND 00/10] arm64/perf: Enable branch stack sampling Will Deacon
2023-07-31 13:05   ` Will Deacon
2023-08-18  3:12   ` Anshuman Khandual
2023-08-18  3:12     ` Anshuman Khandual
2023-08-18 17:56     ` Will Deacon
2023-08-18 17:56       ` Will Deacon
2023-08-21  8:53       ` Anshuman Khandual
2023-08-21  8:53         ` Anshuman Khandual
2023-09-27  8:37 ` Anshuman Khandual
2023-09-27  8:37   ` 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=86il9x5k72.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=acme@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=atishp@rivosinc.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.clark@arm.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=peterz@infradead.org \
    --cc=rkanwal@rivosinc.com \
    --cc=robh@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --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: 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.