Re: [PATCH v5] x86/apic: Use EILVT register count from APIC_EFEAT

[Borislav Petkov <bp@alien8.de>]

On Fri, Sep 25, 2026 at 09:47:06PM +0530, Naveen N Rao (AMD) wrote:
> Future AMD processors will be increasing the number of EILVT registers.
> Rather than hardcoding the maximum EILVT register count and using that
> everywhere, introduce a variable in 'struct apic' to track the EILVT
> register count.
> 
> The number of EILVT registers is exposed through the extended APIC
> Feature Register (APIC_EFEAT) bits 23:16 on platforms that support the
> AMD Extended APIC Register space (X86_FEATURE_EXTAPIC).  Use this to
> initialize the count and fall back to the current default from AMD
> family 0x10 (APIC_EILVT_NR_AMD_10H, which is 4) otherwise. Since this
> value is no longer a compile-time constant, update eilvt_offsets to be
> dynamically allocated.
> 
> Drop the now-redundant APIC_EILVT_NR_MAX macro. Other than during EILVT
> register offset allocation (which now uses apic->eilvt_regs_count), that
> macro was being used in the IBS driver for determining the EILVT offset
> for AMD family 0x10 since the EILVT offsets were not assigned by the
> BIOS. Switch that to use APIC_EILVT_NR_AMD_10H, which reflects the
> correct EILVT register count for that family.
> 
> Note: because the EILVT register count is now derived from APIC_EFEAT,
> it is possible that the register count is less than 4 (1 or 0 even) on
> some AMD K8 parts (rather than the previous default of 4), which should
> more accurately reflect the correct EILVT register count on those parts.

Please, do not talk about *what* the patch is doing in the commit message
- that should be obvious from the diff itself. Rather, concentrate on the
*why* it needs to be done and why your patch exists.

It is perfectly fine to explain non-trivial aspects of the code the patch is
touching but do not regurgitate what it does.

See also https://docs.kernel.org/process/submitting-patches.html for
additional inspiration.

Also, that second note about clamping it:

https://sashiko.dev/#/patchset/20260925161706.1619042-1-naveen%40kernel.org

does sound relevant.

The first one, OTOH, is a very good example of a confused LLM:

"The APIC ExtLvtCnt (XLC) field represents the maximum EILVT index..."

Apparently, it couldn't download the APM.

:-P


> Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
> Tested-by: Manali Shukla <manali.shukla@amd.com>
> Tested-by: Bharata B Rao <bharata@amd.com>

Are you sure they tested your new version so quickly?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette