[PATCH RESEND v4 0/3] x86/apic: Add support for additional AMD EILVT registers

[PATCH RESEND v4 0/3] x86/apic: Add support for additional AMD EILVT registers

[Naveen N Rao (AMD)]

Add support for additional APIC EILVT registers being introduced in 
future AMD processors:
https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB)

This is a resend of v4, rebased on tip/master. Previous posting:
http://lore.kernel.org/r/cover.1784785046.git.naveen@kernel.org

Since then:
- I have retained the macro name 'APIC_EILVT_NR_AMD_10H' since I felt it 
  is accurate, and didn't hear a preference for anything else. Happy to 
  change if needed (Ingo)
- I have gone through Sashiko's findings on the previous versions, and 
  none of those justified a change. Other than the pre-existing issues
  reported by Sashiko, there have been 3 findings:
  1. Sashiko seems to be confusing the Max LVT Register index field in 
     APIC Version Register, with the EILVT Count in EFEAT. The former is 
     the maximum index, while the latter is the count.
  2. Secure AVIC driver handling of EILVTs: that is not impacted by this 
     change since the driver never consults the hypervisor value today. 
     The driver will require separate changes regardless.
  3. Need to clamp the maximum EILVT register count to prevent incorrect 
     MMIO accesses: this is not an issue since all offsets being 
     programmed are appropriately clamped at the source.


- 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

 arch/x86/include/asm/apic.h    |  2 ++
 arch/x86/include/asm/apicdef.h |  2 +-
 arch/x86/events/amd/ibs.c      |  4 ++--
 arch/x86/kernel/apic/apic.c    | 17 +++++++++++++++--
 4 files changed, 20 insertions(+), 5 deletions(-)


base-commit: 461735aa6e8e357fb90d2cf827d2b15ce78a1bc7
-- 
2.55.0

[PATCH RESEND v4 1/3] perf/amd/ibs: Limit the max EILVT register count for AMD family 0x10

[Naveen N Rao (AMD)]

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) <naveen@kernel.org>
Tested-by: Manali Shukla <manali.shukla@amd.com>
---
 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++) {
 		if (get_eilvt(offset))
 			break;
 	}
 	preempt_enable();
 
-	if (offset == APIC_EILVT_NR_MAX) {
+	if (offset == APIC_EILVT_NR_AMD_10H) {
 		pr_debug("No EILVT entry available\n");
 		return;
 	}
-- 
2.55.0

[PATCH RESEND v4 2/3] x86/apic: Introduce a variable to track the number of EILVT registers

[Naveen N Rao (AMD)]

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. Use this to initialize the
count and fall back to the current default (APIC_EILVT_NR_AMD_10H) if
the count is not available.

Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Tested-by: Manali Shukla <manali.shukla@amd.com>
---
 arch/x86/include/asm/apic.h    |  2 ++
 arch/x86/include/asm/apicdef.h |  1 +
 arch/x86/kernel/apic/apic.c    | 10 ++++++++++
 3 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 9cd493d467d4..578cc28b3134 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -317,6 +317,8 @@ struct apic {
 
 	void	(*update_vector)(unsigned int cpu, unsigned int vector, bool set);
 
+	u32	eilvt_regs_count;
+
 	char	*name;
 };
 
diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
index bc125c4429dc..ba7657e75ad1 100644
--- a/arch/x86/include/asm/apicdef.h
+++ b/arch/x86/include/asm/apicdef.h
@@ -134,6 +134,7 @@
 #define		APIC_TDR_DIV_64		0x9
 #define		APIC_TDR_DIV_128	0xA
 #define	APIC_EFEAT	0x400
+#define		APIC_EFEAT_XLC(x)	(((x) >> 16) & 0xff)
 #define	APIC_ECTRL	0x410
 #define APIC_SEOI	0x420
 #define APIC_IER	0x480
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 90025451ace2..c990f403ec7f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -410,6 +410,15 @@ int setup_APIC_eilvt(u8 offset, u8 vector, u8 msg_type, u8 mask)
 }
 EXPORT_SYMBOL_GPL(setup_APIC_eilvt);
 
+static __init void init_eilvt(void)
+{
+	if (cpu_feature_enabled(X86_FEATURE_EXTAPIC))
+		apic->eilvt_regs_count = APIC_EFEAT_XLC(apic_read(APIC_EFEAT));
+
+	if (!apic->eilvt_regs_count && boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+		apic->eilvt_regs_count = APIC_EILVT_NR_AMD_10H;
+}
+
 /*
  * Program the next event, relative to now
  */
@@ -2345,6 +2354,7 @@ static void __init apic_bsp_setup(bool upmode)
 	if (upmode)
 		apic_bsp_up_setup();
 	setup_local_APIC();
+	init_eilvt();
 
 	enable_IO_APIC();
 	end_local_APIC_setup();
-- 
2.55.0

[PATCH RESEND v4 3/3] x86/apic: Drop APIC_EILVT_NR_MAX

[Naveen N Rao (AMD)]

Switch to using apic->eilvt_regs_count as the maximum EILVT register
count. Since this value is no longer a compile-time constant, update
eilvt_offsets to be dynamically allocated.

Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Tested-by: Manali Shukla <manali.shukla@amd.com>
---
 arch/x86/include/asm/apicdef.h | 1 -
 arch/x86/kernel/apic/apic.c    | 7 +++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
index ba7657e75ad1..32a242ae0455 100644
--- a/arch/x86/include/asm/apicdef.h
+++ b/arch/x86/include/asm/apicdef.h
@@ -140,7 +140,6 @@
 #define APIC_IER	0x480
 #define APIC_EILVTn(n)	(0x500 + 0x10 * n)
 #define		APIC_EILVT_NR_AMD_10H	4
-#define		APIC_EILVT_NR_MAX	APIC_EILVT_NR_AMD_10H
 
 #define APIC_BASE (fix_to_virt(FIX_APIC_BASE))
 #define APIC_BASE_MSR		0x800
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index c990f403ec7f..dd734c58b780 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -341,7 +341,7 @@ static void __setup_APIC_LVTT(unsigned int clocks, int oneshot, int irqen)
  * necessarily a BIOS bug.
  */
 
-static atomic_t eilvt_offsets[APIC_EILVT_NR_MAX];
+static atomic_t *eilvt_offsets;
 
 static inline int eilvt_entry_is_changeable(unsigned int old, unsigned int new)
 {
@@ -354,7 +354,7 @@ static unsigned int reserve_eilvt_offset(int offset, unsigned int new)
 {
 	unsigned int rsvd, vector;
 
-	if (offset >= APIC_EILVT_NR_MAX)
+	if (!eilvt_offsets || offset >= apic->eilvt_regs_count)
 		return ~0;
 
 	rsvd = atomic_read(&eilvt_offsets[offset]);
@@ -417,6 +417,9 @@ static __init void init_eilvt(void)
 
 	if (!apic->eilvt_regs_count && boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
 		apic->eilvt_regs_count = APIC_EILVT_NR_AMD_10H;
+
+	if (apic->eilvt_regs_count)
+		eilvt_offsets = kzalloc_objs(atomic_t, apic->eilvt_regs_count);
 }
 
 /*
-- 
2.55.0

Re: [PATCH RESEND v4 0/3] x86/apic: Add support for additional AMD EILVT registers

[Bharata B Rao]

On 03-Sep-26 2:58 PM, Naveen N Rao (AMD) wrote:
> Add support for additional APIC EILVT registers being introduced in 
> future AMD processors:
> https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB)
> 
> This is a resend of v4, rebased on tip/master. Previous posting:
> http://lore.kernel.org/r/cover.1784785046.git.naveen@kernel.org

This change is required by IBS memory profiler as well which is being posted as
one of the hotness sources in pghot patchset
(https://lore.kernel.org/linux-mm/20260728054356.291998-1-bharata@amd.com/)

Tested this series with pghot+ibs memory profiler.

For the series, Tested-by: Bharata B Rao <bharata@amd.com>

Regards,
Bharata.

Re: [PATCH RESEND v4 0/3] x86/apic: Add support for additional AMD EILVT registers

[Borislav Petkov]

On Thu, Sep 03, 2026 at 02:58:38PM +0530, Naveen N Rao (AMD) wrote:
> Add support for additional APIC EILVT registers being introduced in 
> future AMD processors:
> https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB)
> 
> This is a resend of v4, rebased on tip/master. Previous posting:
> http://lore.kernel.org/r/cover.1784785046.git.naveen@kernel.org
> 
> Since then:
> - I have retained the macro name 'APIC_EILVT_NR_AMD_10H' since I felt it 
>   is accurate, and didn't hear a preference for anything else. Happy to 
>   change if needed (Ingo)
> - I have gone through Sashiko's findings on the previous versions, and 
>   none of those justified a change. Other than the pre-existing issues
>   reported by Sashiko, there have been 3 findings:

Except that someone should address the preexisting issues before we pile more
ontop:

https://sashiko.dev/#/patchset/cover.1788425679.git.naveen%40kernel.org

I see Ravi looks like the one who's been most busy here. CCed.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH RESEND v4 0/3] x86/apic: Add support for additional AMD EILVT registers

[Ravi Bangoria]

Hi Boris,

On 15-Sep-26 5:59 AM, Borislav Petkov wrote:
> On Thu, Sep 03, 2026 at 02:58:38PM +0530, Naveen N Rao (AMD) wrote:
>> Add support for additional APIC EILVT registers being introduced in 
>> future AMD processors:
>> https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB)
>>
>> This is a resend of v4, rebased on tip/master. Previous posting:
>> http://lore.kernel.org/r/cover.1784785046.git.naveen@kernel.org
>>
>> Since then:
>> - I have retained the macro name 'APIC_EILVT_NR_AMD_10H' since I felt it 
>>   is accurate, and didn't hear a preference for anything else. Happy to 
>>   change if needed (Ingo)
>> - I have gone through Sashiko's findings on the previous versions, and 
>>   none of those justified a change. Other than the pre-existing issues
>>   reported by Sashiko, there have been 3 findings:
> 
> Except that someone should address the preexisting issues before we pile more
> ontop:
> 
> https://sashiko.dev/#/patchset/cover.1788425679.git.naveen%40kernel.org

All the preexisting IBS issues reported by Sashiko there are applicable only
for the very old family 0x10 AMD processors. Given that, it may not be worth
addressing them unless someone is actually running into the issue in practice.

Thanks,
Ravi