From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA13727F732; Sun, 8 Mar 2026 09:21:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772961717; cv=none; b=n6XdWajRpP/8/z4LCPcIL0HBaAdjKNGCwz7u5OwUNKRaL04dhvQKGGtEhAinnAOIxq0ZMiZNHMXlIwx7AIVkWw+UU1Q+eNYXfbIJkOoYqqfQRxyJ8GeJj6uiwjbJxd4beYhUt3uM8IF3pTtiCvvlCvsYv9ZrS0imLqn5Lg2oJFQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772961717; c=relaxed/simple; bh=MJJg1U6ugjDsNAglWwPOIRpYHhnfFmyzI4DPevXkZT0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=A/ksy9nLaV6KKkuIW/If1f8KbAEguS2cuQl94c0we4uTMkl1GBn47Zjq/Dblix4calIn3AE/RAeSeZp7gk4xIJPUaq9uok52IQnVl+dmymYetlcGNr0Cmgkoo6ZkbB7AtYevkXrpuBnrm5isoV/i1i8ZWlPz8FMZZW3cNVEMpu4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mp6jcEUr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mp6jcEUr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 961ADC116C6; Sun, 8 Mar 2026 09:21:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772961717; bh=MJJg1U6ugjDsNAglWwPOIRpYHhnfFmyzI4DPevXkZT0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mp6jcEUrK5rqtvVUGKENgP6f2t9MOM1AFMdmd1ZpxxwanKePxNKZjbyi/w5edhrNp UC09/Bv+YsYmssAyvjWXXgzF5sqwgR+4M6pNzCEZcsNmew0FTzbuK3UEYhx2EpEAWT 2TbAO2DNUq40E5x99UDBrggBq5NccT1Y5YjaVjHb0MjgXwaJDyQvuPUD2j6kUzsJLc V+gQdTdJ23gHFuxDueJpo5g+LbNVlX2pt3Jtx3koNkhiGWXMvfxeYz2MJ7kZyuO6z4 Dy89D3OBT4ND2QbckEnDXM3LdvyrveE76CcXE4dGwGFt+iPvlqkWv90Plg3hsG4oFf pp6z84vYpJQ5A== From: Thomas Gleixner To: Shashank Balaji , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Suresh Siddha Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Jan Kiszka , Sohil Mehta , Andrew Cooper , Shashank Balaji , Rahul Bukte , Daniel Palmer , Tim Bird , stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] x86/x2apic: Disable x2apic on resume if the kernel expects so In-Reply-To: <20260306-x2apic-fix-v2-1-bee99c12efa3@sony.com> References: <20260306-x2apic-fix-v2-0-bee99c12efa3@sony.com> <20260306-x2apic-fix-v2-1-bee99c12efa3@sony.com> Date: Sun, 08 Mar 2026 10:21:53 +0100 Message-ID: <87a4wi3ccu.ffs@tglx> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Mar 06 2026 at 14:46, Shashank Balaji wrote: > When resuming from s2ram, firmware may re-enable x2apic mode, which may have > been disabled by the kernel during boot either because it doesn't support > irq remapping or for other reasons. This causes the kernel to continue using > the xapic interface, while the hardware is in x2apic mode, which causes hangs. > This happens on defconfig + bare metal + s2ram. > > Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be > disabled, i.e. when x2apic_mode = 0. > > The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep > configuration or initial boot configuration for each CPU, including MSR state: > > 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) > > So at least as per the spec, re-enablement of x2apic by the firmware is allowed > if "x2apic on" is a part of the initial boot configuration. > > [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization > > Fixes: 6e1cb38a2aef ("x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping") > Cc: stable@vger.kernel.org > Co-developed-by: Rahul Bukte > Signed-off-by: Rahul Bukte > Signed-off-by: Shashank Balaji Reviewed-by: Thomas Gleixner