Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji <shashank.mahadasyam@xxxxxxxx>]

On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
> On 2/4/2026 10:07 PM, Shashank Balaji wrote:
> > On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
> 
> >> It's a bit odd then that the firmware chooses to enable x2apic without
> >> the OS requesting it.
> > 
> > Well, the firmware has a setting saying "Enable x2apic", which was
> > enabled. So it did what the setting says
> > 
> 
> The expectation would be that firmware would restore to the same state
> before lapic_suspend().

I'm a bit out of my depth here, but I went looking around, and this is from the
latest ACPI spec (v6.6) [1]:

        When executing from the power-on reset vector as a result of waking
        from an S2 or S3 sleep state, the platform firmware performs only the
        hardware initialization required to restore the system to either the
        state the platform was in prior to the initial operating system boot,
        or to the pre-sleep configuration state. In multiprocessor systems,
        non-boot processors should be placed in the same state as prior to the
        initial operating system boot.

        (further ahead)

         If this is an S2 or S3 wake, then the platform runtime firmware
         restores minimum context of the system before jumping to the waking
         vector. This includes:

                CPU configuration. Platform runtime firmware restores the
                pre-sleep configuration or initial boot configuration of each
                CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts
                must be disabled (for IA-32 processors, disabled by CLI
                instruction).

                (and other things)

I suppose, in my case, the firmware is restoring initial boot
configuration on S3 resume. And initial boot configuration of x2apic is
set from the firmware's UI "Enable x2apic".

> Maybe a warning would be useful to encourage firmware to fix this going
> forward. I don't have a strong preference on the wording, but how about?
> 
> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
> resume.\n");

At least as per the spec, it's not something the firmware needs to fix,
and it's not unexpected re-enablement.

Am I missing something?

But it _is_ surprising that this bug went unnoticed for so long :)

[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization