From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD284C001DF for ; Wed, 2 Aug 2023 19:16:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230076AbjHBTQc (ORCPT ); Wed, 2 Aug 2023 15:16:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229707AbjHBTQb (ORCPT ); Wed, 2 Aug 2023 15:16:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03545E7D; Wed, 2 Aug 2023 12:16:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 73C2B61ADB; Wed, 2 Aug 2023 19:16:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE9D8C433C8; Wed, 2 Aug 2023 19:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691003789; bh=XBtPzjHQlXNIEQFLxSA/ttht8PBVws+eh+Spm9Nkkoo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Tnffh/SxD2Pjn+liTTmM1Pvc2lh1VRW6FzrlIqRiNgNSaC5W+VxiiYVzIISQ2Q6kO Gscg6nPQ3PIPDBk4PTi24qW6Y45kUbIA/fKa+sglBgFHYPwVxtmZAFNPLrLBhZ54ih od5C4emkLRQ5qa2W+Y/KaOY0L31r8affvuO6j1j1OEQMcZ5Y4dEoqZ+KZAL332oHPL gfWJCa6CCVTJAOfCYQDWfIx5Id/0KcgtqyKqOvgMtJbko4sLlP8gxBZopaqcE9xO/8 KETQ/yBbUDD+lHfyE32XFHLQGGRCevdmBvyvxti1LshHX5xhkgRRqwBdGIH49F+8vO +Igzi7c09aB5A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qRHKd-001T2k-Ap; Wed, 02 Aug 2023 20:16:27 +0100 Date: Wed, 02 Aug 2023 20:16:17 +0100 Message-ID: <86il9x5k72.wl-maz@kernel.org> From: Marc Zyngier To: Rajnesh Kanwal 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 In-Reply-To: <20230802115931.12212-1-rkanwal@rivosinc.com> References: <20230711082455.215983-10-anshuman.khandual@arm.com> <20230802115931.12212-1-rkanwal@rivosinc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rkanwal@rivosinc.com, 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On Wed, 02 Aug 2023 12:59:31 +0100, Rajnesh Kanwal 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.