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 07E06C3DA64 for ; Tue, 6 Aug 2024 06:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Cc:To:Subject:From:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bbegJZabCx9GBfzv+ox4omUibO2uSOQbgmoKcDLP3zU=; b=rNFKQgNLI2papF7CX8XJBYRwRk Fmw1VZA094mbUcydsKnUNY46+oE4I8h9x/Jx5/MvBGgutoiV49onXK3xT0K2dW6IuwevJnis0RoYy RdAF+fPZ60IRSO6Enpu4yfJoa6oTXCanKsObTJVMvyATqZBfR+wPwzhqihVPKYJKZ/uluWXfsbYka 3+tO+ZzTJimGsqtCOwYVvewAyXY3x0q8DGpYkAtlLUk00fK88bRA4BFAm7BvKN2nsV4K8TzOS3I70 sJbYG+Lqy1REYMvkhE/S8Lkf5uKbDhlHdApClC557hhrWQmwo92z7dNMpUwzGWO6Y5qtqAxTBwLlr rGTMgyDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbE0R-00000000hyL-3kkj; Tue, 06 Aug 2024 06:49:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbDzv-00000000hun-34uj for linux-arm-kernel@lists.infradead.org; Tue, 06 Aug 2024 06:48:44 +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 6B1E7106F; Mon, 5 Aug 2024 23:49:07 -0700 (PDT) Received: from [10.163.54.208] (unknown [10.163.54.208]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B4693F5A1; Mon, 5 Aug 2024 23:48:36 -0700 (PDT) Message-ID: Date: Tue, 6 Aug 2024 12:18:27 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Anshuman Khandual Subject: Re: [RFC V2 1/3] arm64/cpufeature: Add field details for ID_AA64DFR1_EL1 register To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Jonathan Corbet , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Catalin Marinas , Mark Brown , Mark Rutland , kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org References: <20240620092607.267132-1-anshuman.khandual@arm.com> <20240620092607.267132-2-anshuman.khandual@arm.com> <20240805135942.GA9866@willie-the-truck> Content-Language: en-US In-Reply-To: <20240805135942.GA9866@willie-the-truck> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240805_234843_888748_23BD0BE0 X-CRM114-Status: GOOD ( 19.58 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/5/24 19:29, Will Deacon wrote: > On Thu, Jun 20, 2024 at 02:56:05PM +0530, Anshuman Khandual wrote: >> This adds required field details for ID_AA64DFR1_EL1, and also drops dummy >> ftr_raz[] array which is now redundant. These register fields will be used >> to enable increased breakpoint and watchpoint registers via FEAT_Debugv8p9 >> later. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> cc: Mark Brown >> Cc: Mark Rutland >> Cc: Marc Zyngier >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> arch/arm64/kernel/cpufeature.c | 21 ++++++++++++++++----- >> 1 file changed, 16 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c >> index 48e7029f1054..12f0a5181bf2 100644 >> --- a/arch/arm64/kernel/cpufeature.c >> +++ b/arch/arm64/kernel/cpufeature.c >> @@ -527,6 +527,21 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = { >> ARM64_FTR_END, >> }; >> >> +static const struct arm64_ftr_bits ftr_id_aa64dfr1[] = { >> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR1_EL1_ABL_CMPs_SHIFT, 8, 0), >> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR1_EL1_DPFZS_SHIFT, 4, 0), > > I only got this far in the patch, but why is this FTR_STRICT + > FTR_LOWER_SAFE? The behaviour of the cycle counter on an SPE management > event sounds like it would be fine to differ between cores, no? You are right I guess, will this change as FTR_NONSTRICT instead. > > Please go through all the new fields, bearing in mind that most of the > PMU stuff is per-CPU type rather than global. Looking at all the register fields in ID_AA64DFR1_EL1 as in the latest ARM ARM DDI 0487K.a. Overall there are two different register field categories, the first is whether an arch feature is enabled or not. This should be all the same across different cpus on the system, hence FTR_STRICT + FTR_LOWER_SAFE probably makes sense. The second type is number of HW counter or element entries per CPU/PMU which can be different across cpus, hence FTR_NONSTRICT + FTR_LOWER_SAFE might be applicable in such cases. 1. ABL_CMPs - Number of breakpoints that support address linking, minus 1 [FTR_NONSTRICT + FTR_LOWER_SAFE] 2. DPFZS - Behavior of the cycle counter when event counting is frozen by a Statistical Profiling management event [FTR_NONSTRICT + FTR_LOWER_SAFE] 3. EBEP - Exception-based event profiling [FTR_STRICT + FTR_LOWER_SAFE] 4. ITE - Instrumentation Trace Extension [FTR_STRICT + FTR_LOWER_SAFE] 5. ABLE - Address Breakpoint Linking Extension [FTR_STRICT + FTR_LOWER_SAFE] 6. PMICNTR - PMU fixed-function instruction counter - Could this vary between cpus ? [FTR_NONSTRICT + FTR_LOWER_SAFE] 7. SPMU - System PMU extension [FTR_STRICT + FTR_LOWER_SAFE] 8. CTX_CMPs - Context-aware breakpoints [FTR_NONSTRICT + FTR_LOWER_SAFE] 9. WRPs - Watchpoints [FTR_NONSTRICT + FTR_LOWER_SAFE] 10. BRPs - Breakpoints [FTR_NONSTRICT + FTR_LOWER_SAFE] 11. SYSPMUID - System PMU ID [FTR_STRICT + FTR_LOWER_SAFE] Although please note that existing breakpoint/watchpoint numbers are represented as FTR_STRICT + FTR_LOWER_SAFE. Hence just wondering if these extended watchpoint or breakpoint numbers should represented any different. static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = { .............. ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_CTX_CMPs_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_WRPs_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_BRPs_SHIFT, 4, 0), .............. }; Please suggest if any of the above needs change. Thank you. - Anshuman