Re: [PATCH v2 0/3] Support additional AMD EILVT registers

[Naveen N Rao <naveen@kernel.org>]

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