linux-kernel - Re: [PATCH V13 - RESEND 09/10] arm64/perf: Implement branch records save on task sched out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86il9x5k72.wl-maz@kernel.org>
Date:   Wed, 02 Aug 2023 20:16:17 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Rajnesh Kanwal <rkanwal@...osinc.com>
Cc:     anshuman.khandual@....com, acme@...nel.org, broonie@...nel.org,
        catalin.marinas@....com, james.clark@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org, mark.rutland@....com,
        mingo@...hat.com, peterz@...radead.org, robh@...nel.org,
        suzuki.poulose@....com, will@...nel.org, atishp@...osinc.com
Subject: Re: [PATCH V13 - RESEND 09/10] arm64/perf: Implement branch records save on task sched out

On Wed, 02 Aug 2023 12:59:31 +0100,
Rajnesh Kanwal <rkanwal@...osinc.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.