From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79D443D6CD9 for ; Thu, 23 Jul 2026 16:40:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784824805; cv=none; b=Uf9zcpAmOm9FUinRDC2TL56wg9dvc52fHuERHflKjxlO9KvrsoxtrsEdcvJczCNw7t7eoc1UcwDm7ABlRnrFozVrxLCjVkk03942bHVlPsqRD8WYi5dQRfuW4a+ecvQDwFSAOpZCjJJvATdU+V8BIT7J7tdsU7jBT7O3YJCMo2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784824805; c=relaxed/simple; bh=68t6x8n7+8q9o2+gnMl9sMecjpK228nZ2WDw3MDL4Go=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B6lfp3yPu+Cf93GsiYHwTzy0nv0362uwI4iXLGA22UdIckHj4ZTVCbQd8H/MAVur9yEfCuuSiYgumvs2kjVKK+X6Ur8ujeyESbG0POmNe88hxziuFstSM0goCcgVSXEyOYNQ5CPtch7+oIsf46qZ1kfLTbgneYpFuL9Y8fTNHP4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E42301F000E9; Thu, 23 Jul 2026 16:39:59 +0000 (UTC) Date: Thu, 23 Jul 2026 21:56:42 +0530 From: Naveen N Rao To: Ingo Molnar Cc: Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Nikunj A Dadhania , Manali Shukla , Bharata B Rao , "H. Peter Anvin" Subject: Re: [PATCH v4 1/3] perf/amd/ibs: Limit the max EILVT register count for AMD family 0x10 Message-ID: References: <2d18caf834a2e66e4c6787e3c3058fd6bb6e5d3e.1784785046.git.naveen@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Ingo, On Thu, Jul 23, 2026 at 10:02:51AM +0200, Ingo Molnar wrote: > > * Naveen N Rao (AMD) wrote: > > > For AMD family 0x10, EILVT offsets are not assigned by BIOS and is > > instead assigned by picking the next available EILVT offset. Use the > > maximum EILVT count for family 0x10 (APIC_EILVT_NR_AMD_10H) rather than > > an arbitrary maximum EILVT count when looking for the next available > > EILVT offset. > > > > Signed-off-by: Naveen N Rao (AMD) > > Tested-by: Manali Shukla > > --- > > arch/x86/events/amd/ibs.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c > > index 3531f9c23b8c..555912ac520f 100644 > > --- a/arch/x86/events/amd/ibs.c > > +++ b/arch/x86/events/amd/ibs.c > > @@ -1839,13 +1839,13 @@ static void force_ibs_eilvt_setup(void) > > > > preempt_disable(); > > /* find the next free available EILVT entry, skip offset 0 */ > > - for (offset = 1; offset < APIC_EILVT_NR_MAX; offset++) { > > + for (offset = 1; offset < APIC_EILVT_NR_AMD_10H; offset++) { > > Nit: > > s/APIC_EILVT_NR_AMD_10H > /APIC_EILVT_NR_MAX_AMD_10H > > to make it clear at first sight that this is a (family specific) > maximum, not some default count or other random value. While trying to make this change, I realized _NR_MAX_ may not be accurate either. APIC_EILVT_NR_AMD_10H is actually representing the number of EILVT registers on AMD processor family 0x10 as a fixed entity (not a family specific maximum which would imply that the count can be less). This particular function (force_ibs_eilvt_setup()) is specific to AMD 0x10 family. So, the name does seem reasonable to me in hindsight. I believe its use in the for loop above, and going from a macro that represents a generic maximum count to a family-specific count feels less intuitive. I'm leaning towards retaining the current name or renaming it to APIC_EILVT_COUNT_AMD_10H to represent the EILVT register count. Thoughts? Thanks, Naveen