[PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[Grzegorz Jaszczyk]

During early boot, the generic x86 kernel defaults to the MMIO-based
APIC driver (apic_physflat). However, if the kernel is booted (e.g. via
kexec) when x2apic is already enabled in hardware, the MMIO interface to
the APIC is disabled.

Normally, ACPI MADT probing would install an x2APIC driver early.
However, if ACPI is disabled (e.g., CONFIG_ACPI is not set, as in
crashdump kernels), x86_64_probe_apic() does not run until late_time_init()
via apic_intr_mode_init().

This creates a window between local_irq_enable() and late_time_init()
where interrupts are enabled, but the APIC driver pointer still points
to apic_physflat. Because check_x2apic() detected hardware x2APIC mode
and set x2apic_mode = 1, init_apic_mappings() skipped mapping the APIC
fixmap. If a pending interrupt (e.g., left in IRR across kexec on
secondary CPUs) fires during this window, native_apic_mem_eoi() is
invoked, which attempts to write to the unmapped APIC EOI register,
triggering an immediate kernel page fault (#PF).

To prevent this, check if x2apic is enabled in hardware during early APIC
call setup in apic_setup_apic_calls() and switch the default APIC driver
from apic_physflat to apic_x2apic_phys immediately. This ensures that any
early EOI writes use safe MSR-based accesses. The driver can still be
upgraded later during the normal APIC probe phase.

Signed-off-by: Grzegorz Jaszczyk <jaszczyk@chromium.org>
---
 arch/x86/kernel/apic/init.c        |  2 ++
 arch/x86/kernel/apic/local.h       |  5 +++++
 arch/x86/kernel/apic/x2apic_phys.c | 10 ++++++++++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/kernel/apic/init.c b/arch/x86/kernel/apic/init.c
index 821e2e536f19..c48323f725e7 100644
--- a/arch/x86/kernel/apic/init.c
+++ b/arch/x86/kernel/apic/init.c
@@ -82,6 +82,8 @@ static __init void update_static_calls(void)
 
 void __init apic_setup_apic_calls(void)
 {
+	x2apic_phys_early_init();
+
 	/* Ensure that the default APIC has native_eoi populated */
 	apic->native_eoi = apic->eoi;
 	update_static_calls();
diff --git a/arch/x86/kernel/apic/local.h b/arch/x86/kernel/apic/local.h
index 090dd71837aa..0c33eaa3b03a 100644
--- a/arch/x86/kernel/apic/local.h
+++ b/arch/x86/kernel/apic/local.h
@@ -20,6 +20,11 @@ void x2apic_send_IPI_all(int vector);
 void x2apic_send_IPI_allbutself(int vector);
 void x2apic_send_IPI_self(int vector);
 extern u32 x2apic_max_apicid;
+#ifdef CONFIG_X86_X2APIC
+void x2apic_phys_early_init(void);
+#else
+static inline void x2apic_phys_early_init(void) { }
+#endif
 
 /* IPI */
 
diff --git a/arch/x86/kernel/apic/x2apic_phys.c b/arch/x86/kernel/apic/x2apic_phys.c
index 090647cc5a78..c41f47aed7ab 100644
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -155,3 +155,13 @@ static struct apic apic_x2apic_phys __ro_after_init = {
 };
 
 apic_driver(apic_x2apic_phys);
+
+void __init x2apic_phys_early_init(void)
+{
+	if (x2apic_enabled()) {
+		apic = &apic_x2apic_phys;
+		if (apic->x2apic_set_max_apicid)
+			apic->max_apic_id = x2apic_max_apicid;
+		pr_info("Switched default APIC to: %s\n", apic->name);
+	}
+}
-- 
2.55.0.1003.g10538fe699-goog

Re: [PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[Dave Hansen]

On 9/10/26 02:04, Grzegorz Jaszczyk wrote:
> During early boot, the generic x86 kernel defaults to the MMIO-based
> APIC driver (apic_physflat). However, if the kernel is booted (e.g. via
> kexec) when x2apic is already enabled in hardware, the MMIO interface to
> the APIC is disabled.

There's also some new hardware that locks the hardware in x2apic mode. I
wonder if it has a similar problem.

> Normally, ACPI MADT probing would install an x2APIC driver early.
> However, if ACPI is disabled (e.g., CONFIG_ACPI is not set, as in
> crashdump kernels), x86_64_probe_apic() does not run until late_time_init()
> via apic_intr_mode_init().

Is this "default_acpi_madt_oem_check()" that uses apic_install_driver()?

> This creates a window between local_irq_enable() and late_time_init()
> where interrupts are enabled, but the APIC driver pointer still points
> to apic_physflat. Because check_x2apic() detected hardware x2APIC mode
> and set x2apic_mode = 1, init_apic_mappings() skipped mapping the APIC
> fixmap. If a pending interrupt (e.g., left in IRR across kexec on
> secondary CPUs) fires during this window, native_apic_mem_eoi() is
> invoked, which attempts to write to the unmapped APIC EOI register,
> triggering an immediate kernel page fault (#PF).

Long-term, it seems like reducing the use of x2apic_mode would be really
nice.

> To prevent this, check if x2apic is enabled in hardware during early APIC
> call setup in apic_setup_apic_calls() and switch the default APIC driver
> from apic_physflat to apic_x2apic_phys immediately. This ensures that any
> early EOI writes use safe MSR-based accesses. The driver can still be
> upgraded later during the normal APIC probe phase.
>
> 
> diff --git a/arch/x86/kernel/apic/init.c b/arch/x86/kernel/apic/init.c
> index 821e2e536f19..c48323f725e7 100644
> --- a/arch/x86/kernel/apic/init.c
> +++ b/arch/x86/kernel/apic/init.c
> @@ -82,6 +82,8 @@ static __init void update_static_calls(void)
>  
>  void __init apic_setup_apic_calls(void)
>  {
> +	x2apic_phys_early_init();
> +
>  	/* Ensure that the default APIC has native_eoi populated */
>  	apic->native_eoi = apic->eoi;
>  	update_static_calls();

This seems a bit ad-hoc.

>  apic_driver(apic_x2apic_phys);
> +
> +void __init x2apic_phys_early_init(void)
> +{
> +	if (x2apic_enabled()) {
> +		apic = &apic_x2apic_phys;
> +		if (apic->x2apic_set_max_apicid)
> +			apic->max_apic_id = x2apic_max_apicid;
> +		pr_info("Switched default APIC to: %s\n", apic->name);
> +	}
> +}

This seems to be a subset of what apic_install_driver() and
apic_x2apic_phys->probe() do, down do the pr_info().

Even if those are overkill for this, it would be nice to use them for
consistency if they function.

It also seems like some of the more obscure apic drivers depend on
x2apic_mode. They also seem like they might be selected by the MADT
search. Could this end up overwriting those?

Maybe this is too much work for the task at hand, but this does seem to
show that there's some information missing from 'struct apic'. Say
apic_physflat had an ->initialized() that was false until its MMIO was
unmapped and apic_x2apic_phys->initialized() pointed over to:
x2apic_enabled().

apic_setup_apic_calls()
{
	// Search for an APIC driver that is initialized:
	for_each(drv) {
		if (!drv->initialized())
			continue;
		
		apic_install_driver(drv);
	}
}

Basically, I'm wondering if it's worth continuing to special-case x2apic
handling or whether it should just be a part of the apic driver
infrastructure.

Re: [PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[Thomas Gleixner]

On Thu, Sep 10 2026 at 09:04, Grzegorz Jaszczyk wrote:
> To prevent this, check if x2apic is enabled in hardware during early APIC
> call setup in apic_setup_apic_calls() and switch the default APIC driver
> from apic_physflat to apic_x2apic_phys immediately. This ensures that any
> early EOI writes use safe MSR-based accesses. The driver can still be
> upgraded later during the normal APIC probe phase.

That's really the wrong place. Initializing those calls has absolutely
nothing to do with the driver probing.

There is quite some historical ballast in this whole APIC driver
probing, which I never came around to clean up.

I'll have a look how this can be done sanely without replicating half of
the existing code just to paper over the real issue.

Thanks,

        tglx

Re: [PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[Grzegorz Jaszczyk]

On Thu, Sep 10, 2026 at 5:23 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 9/10/26 02:04, Grzegorz Jaszczyk wrote:
> > During early boot, the generic x86 kernel defaults to the MMIO-based
> > APIC driver (apic_physflat). However, if the kernel is booted (e.g. via
> > kexec) when x2apic is already enabled in hardware, the MMIO interface to
> > the APIC is disabled.
>
> There's also some new hardware that locks the hardware in x2apic mode. I
> wonder if it has a similar problem.

You are probably referring to "x86/apic: Don't disable x2APIC if
locked" - if so, it seems it will have the same problem whenever ACPI
MADT probing doesn't run early (e.g. in CONFIG_ACPI=n crashdump
kernels).

In both cases (locked by hardware/BIOS or handed over via kexec), the
CPU starts with x2APIC enabled. As Intel SDM section "11.12.2 x2APIC
Register Availability" states: "In x2APIC mode, the memory mapped
interface is not available and any access to the MMIO interface will
behave similar to that of a legacy xAPIC in globally disabled state."

>
> > Normally, ACPI MADT probing would install an x2APIC driver early.
> > However, if ACPI is disabled (e.g., CONFIG_ACPI is not set, as in
> > crashdump kernels), x86_64_probe_apic() does not run until late_time_init()
> > via apic_intr_mode_init().
>
> Is this "default_acpi_madt_oem_check()" that uses apic_install_driver()?

Yes


> >  apic_driver(apic_x2apic_phys);
> > +
> > +void __init x2apic_phys_early_init(void)
> > +{
> > +     if (x2apic_enabled()) {
> > +             apic = &apic_x2apic_phys;
> > +             if (apic->x2apic_set_max_apicid)
> > +                     apic->max_apic_id = x2apic_max_apicid;
> > +             pr_info("Switched default APIC to: %s\n", apic->name);
> > +     }
> > +}
>
> This seems to be a subset of what apic_install_driver() and
> apic_x2apic_phys->probe() do, down do the pr_info().
>
> Even if those are overkill for this, it would be nice to use them for
> consistency if they function.

Ok, I can use apic_install_driver() instead. When it comes to
apic_x2apic_phys->probe() it can't really be used in current form
because at this early stage x2apic_phys_probe() will return 0, since
x2apic_mode is set quite late in setup.c (check_x2apic()).

>
> It also seems like some of the more obscure apic drivers depend on
> x2apic_mode. They also seem like they might be selected by the MADT
> search. Could this end up overwriting those?

It should be the other way around: MADT is called after
apic_setup_apic_calls() and it will overwirte it as normal: just this
time instead of overwriting apic_physflat it will overwrite
apic_x2apic_phys.

>
> Maybe this is too much work for the task at hand, but this does seem to
> show that there's some information missing from 'struct apic'. Say
> apic_physflat had an ->initialized() that was false until its MMIO was
> unmapped and apic_x2apic_phys->initialized() pointed over to:
> x2apic_enabled().
>
> apic_setup_apic_calls()
> {
>         // Search for an APIC driver that is initialized:
>         for_each(drv) {
>                 if (!drv->initialized())
>                         continue;
>
>                 apic_install_driver(drv);
>         }
> }
>
> Basically, I'm wondering if it's worth continuing to special-case x2apic
> handling or whether it should just be a part of the apic driver
> infrastructure.

Yeah, something like this will work. Following your suggestion I was
thinking about something like this:

     void __init apic_setup_apic_calls(void)
     {
    +    struct apic **drv;
    +
    +    for (drv = __apicdrivers; drv < __apicdrivers_end; drv++) {
    +        if ((*drv)->early_probe && (*drv)->early_probe()) {
    +            apic_install_driver(*drv);
    +            break;
    +        }
    +    }

and as apic_x2apic_phys.early_probe() we could use existing
x2apic_enabled(). And in apic_physflat, an early_probe returning
!x2apic_enabled(). But I see that Thomas also responded, and I think
he is looking into a different approach.

Thanks,
Grzegorz

Re: [PATCH] x86/apic: Switch to x2apic driver early if x2apic is enabled

[Grzegorz Jaszczyk]

On Fri, Sep 11, 2026 at 2:51 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Thu, Sep 10 2026 at 09:04, Grzegorz Jaszczyk wrote:
> > To prevent this, check if x2apic is enabled in hardware during early APIC
> > call setup in apic_setup_apic_calls() and switch the default APIC driver
> > from apic_physflat to apic_x2apic_phys immediately. This ensures that any
> > early EOI writes use safe MSR-based accesses. The driver can still be
> > upgraded later during the normal APIC probe phase.
>
> That's really the wrong place. Initializing those calls has absolutely
> nothing to do with the driver probing.
>
> There is quite some historical ballast in this whole APIC driver
> probing, which I never came around to clean up.
>
> I'll have a look how this can be done sanely without replicating half of
> the existing code just to paper over the real issue.
>

Ok, understood. Thank you. Let me know when you have something to look
at or test.

Thanks,
Grzegorz