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 90D41419303 for ; Tue, 30 Jun 2026 13:28:12 +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=1782826093; cv=none; b=mr2G0URonBZq5IL/Zjq59hp/ZD7RzxlYR8kTEgtdKUmJU7EgYxfAaDgQmnmYJ1NBtAk10OIO+3/bKeqrd0PIrrW8o3em0Slkrv+RiarKpeXJvr+5Zyy2F16EcuaJuY8gUgVgPQ8rCU4tm7XmR+fr9dzwKJJl8ZyQcJF8xAY/QmE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782826093; c=relaxed/simple; bh=mGNRIsBYCJVJg08q5xHQwMJyAvjlD6SVSw3SbztVNiU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CnyBw1ryhiBc47LZmJ6E+XQIua4CRBcWcdSwLpz/m/Ma5o5rlVD4HCTfmGHizEEomK1t5HY6odwtUlUZiCj/6oFvwsLPn3Jd+trdqzcOmo0Evwb0sqtW2bmSED6GODDvR1+5vzVBp7gEJKnq9iC3Pr/Odhez106n/VI6Gc6HU/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JM+2//j8; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JM+2//j8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 967E01F000E9; Tue, 30 Jun 2026 13:28:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782826092; bh=PI8LCmoXhsUkbQjZvKuup0yk22DUMQapbS4P/0IcJoo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JM+2//j8imTaFZPb8B4ks4UIAr/xWpbvhtK5anXO9tOgHV5EZdoHHxetvMOuaJc4z thcrjaiZ8spfe3aV3rBOSFkvybHBqh88fLU1ZFzTO9YVKo2uKjFV7JQoTjQTjtqi5l CAQ2HIrbvvQT2mwPlrm5THPtOMN7nnU9fZnTLwVrejfFaLPaZD+BROeNppZ0jSJjgy PGfcatq/Zzpfe81MED+Tf62GcA0/0oze3QGNrXwSUb/uBvPVamd3g5l29lowqbpfFv 0ERCm0j8bpsw35PjjpEnWkGYoFE8Zb+enjBfBxPVdUsm9OLTeXCvZjPrrXaXs++QSA 8tC72QzePThog== Date: Tue, 30 Jun 2026 18:50:45 +0530 From: Naveen N Rao To: x86@kernel.org, Borislav Petkov Cc: Thomas Gleixner , Dave Hansen , "H. Peter Anvin" , Nikunj A Dadhania , Manali Shukla , Bharata B Rao , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] Support additional AMD EILVT registers Message-ID: References: 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: On Tue, May 12, 2026 at 07:49:14PM +0530, Naveen N Rao (AMD) wrote: > This is v2 of the series posted at: > http://lore.kernel.org/r/cover.1775019269.git.naveen@kernel.org > > Changes since v1: > - Drop the first two patches that were merged > - Call init_eilvt() from apic_bsp_setup(), rather than > setup_local_APIC() so as not to call an __init function from a > non-init function. (Kernel 0-day bot) > - Initialize eilvt count to APIC_EILVT_NR_AMD_10H and allocate > eilvt_offsets array only on AMD processors. > > Manali, > I am retaining your Tested-by: tag since the changes are minimal, but > please reply here if you have concerns with the changes. > > -- > Future AMD processors will be increasing the number of APIC EILVT > registers (*). This series adds support for the same along with some > related cleanups. > > (*) https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB) > > > - Naveen > > > Naveen N Rao (AMD) (3): > perf/amd/ibs: Limit the max EILVT register count for AMD family 0x10 > x86/apic: Introduce a variable to track the number of EILVT registers > x86/apic: Drop APIC_EILVT_NR_MAX and switch to using apic_eilvt_count A gentle ping on this - this still seems to apply cleanly on top of tip/master. If the Sashiko reviews are a concern, the main comment has been about the EILVT count (apart from a separate pre-existing issue): "The architectural specification defines the hardware register count as ExtLvtCnt plus one. Bypassing the increment truncates the maximum accessible offset." It isn't clear to me where Sashiko is getting that. Per APM Section 16.3.5 Extended APIC Feature Register: "Extended LVT Count (XLC) - (Bits 23:16) Specifies the number of extended local vector table registers in the local APIC." That's clear that the count is the actual number of eLVT registers, and this has been verified on actual hardware. - Naveen