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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 479B8C7EE29 for ; Fri, 9 Jun 2023 12:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ICCuAbrIPemziQOw7d94Mt5Lu2D0RpYIeqH7KWANQ0M=; b=M8xMMEk4EjnuKG eyiFjNpj7Mzp1BJSt8HNm+o/qp0pVxNDIK7BPEOGtyol8OLfNE8lsiU+CPYWrsY1EXjtPvHf2YaFo m5sAcb3iO0QzEaNnd4e/BKsBBltVgLPAP7Kpjwv9jZbAB7r2hr7XS2Vfmf2Ifr+p+fVm/+mH+Oxs2 d89W2yaVn6brCDJebKOg2kMRhWH/r491NYq5YB36+mF++vN7mu1Gg2FwTM2rCDXZv1PGmbR6wRnoY mnMqhE0xlJxtol6AqBCgJFTWY4DBxcm3T3NIt5ncE56iKn1FM6OV7d5kcN8yBD4ib/KLyPIhP/ONr BBr+XYuKOINb1rpKxywA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7bS1-00D0ub-0b; Fri, 09 Jun 2023 12:42:45 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7bRw-00D0tr-1X for linux-arm-kernel@lists.infradead.org; Fri, 09 Jun 2023 12:42:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 67B61AB6; Fri, 9 Jun 2023 05:43:24 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.38.153]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D34D3F6C4; Fri, 9 Jun 2023 05:42:37 -0700 (PDT) Date: Fri, 9 Jun 2023 13:42:34 +0100 From: Mark Rutland To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, Mark Brown , James Clark , Rob Herring , Marc Zyngier , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org Subject: Re: [PATCH V11 06/10] arm64/perf: Enable branch stack events via FEAT_BRBE Message-ID: References: <20230531040428.501523-1-anshuman.khandual@arm.com> <20230531040428.501523-7-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230609_054240_631511_27377E5E X-CRM114-Status: GOOD ( 23.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 09, 2023 at 10:17:19AM +0530, Anshuman Khandual wrote: > On 6/5/23 19:13, Mark Rutland wrote: > >> +/* > >> + * A branch record with BRBINFx_EL1.LASTFAILED set, implies that all > >> + * preceding consecutive branch records, that were in a transaction > >> + * (i.e their BRBINFx_EL1.TX set) have been aborted. > >> + * > >> + * Similarly BRBFCR_EL1.LASTFAILED set, indicate that all preceding > >> + * consecutive branch records up to the last record, which were in a > >> + * transaction (i.e their BRBINFx_EL1.TX set) have been aborted. > >> + * > >> + * --------------------------------- ------------------- > >> + * | 00 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX success] > >> + * --------------------------------- ------------------- > >> + * | 01 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX success] > >> + * --------------------------------- ------------------- > >> + * | 02 | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 0 | > >> + * --------------------------------- ------------------- > >> + * | 03 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed] > >> + * --------------------------------- ------------------- > >> + * | 04 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed] > >> + * --------------------------------- ------------------- > >> + * | 05 | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 1 | > >> + * --------------------------------- ------------------- > >> + * | .. | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 0 | > >> + * --------------------------------- ------------------- > >> + * | 61 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed] > >> + * --------------------------------- ------------------- > >> + * | 62 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed] > >> + * --------------------------------- ------------------- > >> + * | 63 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed] > >> + * --------------------------------- ------------------- > >> + * > >> + * BRBFCR_EL1.LASTFAILED == 1 > >> + * > >> + * BRBFCR_EL1.LASTFAILED fails all those consecutive, in transaction > >> + * branches records near the end of the BRBE buffer. > >> + * > >> + * Architecture does not guarantee a non transaction (TX = 0) branch > >> + * record between two different transactions. So it is possible that > >> + * a subsequent lastfailed record (TX = 0, LF = 1) might erroneously > >> + * mark more than required transactions as aborted. > >> + */ > > Linux doesn't currently support TME (and IIUC no-one has built it), so can't we > > delete the transaction handling for now? We can add a comment with somehing like: > > > > /* > > * TODO: add transaction handling for TME. > > */ > > > > Assuming no-one has built TME, we might also be able to get an architectural > > fix to disambiguate the boundary between two transactions, and avoid the > > problem described above. > > > > [...] > > > > OR can leave this unchanged for now. Then update it if and when the relevant > architectural fix comes in. The current TME branch records handling here, is > as per the current architectural specification. My rationale for deleting it is that it cannot be used and cannot be tested, since the kernel doesn't support TME, and there are no TME implementations out there. If and when we support TME in the kernel, this is very likely to have bit-rotted. I'd be happy to link to the current version, e.g. /* * TODO: add transaction handling for FEAT_TME. See: * * https://lore.kernel.org/linux-arm-kernel/20230531040428.501523-7-anshuman.khandual@arm.com/ */ I do appreciate that time and effort has gone into writing this, but IMO it's more distracting than helpful at present, and deleting it makes this easier to review and maintain. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel