From: Sohil Mehta <sohil.mehta@intel.com>
To: Shashank Balaji <shashank.mahadasyam@sony.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Suresh Siddha <suresh.b.siddha@intel.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Long Li <longli@microsoft.com>,
Ajay Kaher <ajay.kaher@broadcom.com>,
Alexey Makhalov <alexey.makhalov@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Ingo Molnar <mingo@elte.hu>, <linux-kernel@vger.kernel.org>,
<linux-hyperv@vger.kernel.org>, <virtualization@lists.linux.dev>,
<jailhouse-dev@googlegroups.com>, <kvm@vger.kernel.org>,
<xen-devel@lists.xenproject.org>,
Rahul Bukte <rahul.bukte@sony.com>,
Daniel Palmer <daniel.palmer@sony.com>,
Tim Bird <tim.bird@sony.com>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
Date: Thu, 5 Feb 2026 15:18:58 -0800 [thread overview]
Message-ID: <e5ac3272-795b-488c-b767-290fd50f2105@intel.com> (raw)
In-Reply-To: <aYQzhRN83rJx6DSb@JPC00244420>
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().
>
>>> Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
>>> firmware during resume. Disabling\n"?
>>
>> I mainly want to make sure the firmware is really at fault before we add
>> such a print. But it seems likely now that the firmware messed up.
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");
A few nits:
For the code comments, you can use more of the line width. Generally, 72
(perhaps even 80) chars is okay for comments dependent on the code in
the vicinity.
The tip tree has slightly unique preferences, such as capitalizing the
first word of the patch title.
Please refer:
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
next prev parent reply other threads:[~2026-02-05 23:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 9:51 [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram Shashank Balaji
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
2026-02-02 15:02 ` kernel test robot
2026-02-02 22:31 ` kernel test robot
2026-02-03 0:24 ` Shashank Balaji
2026-02-03 21:08 ` Sohil Mehta
2026-02-04 9:17 ` Shashank Balaji
2026-02-04 18:53 ` Sohil Mehta
2026-02-05 6:07 ` Shashank Balaji
2026-02-05 23:18 ` Sohil Mehta [this message]
2026-02-06 3:44 ` Shashank Balaji
2026-02-06 8:57 ` Shashank Balaji
2026-02-07 0:37 ` Sohil Mehta
2026-02-02 9:51 ` [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP Shashank Balaji
2026-02-02 11:35 ` Andrew Cooper
2026-02-02 11:54 ` Jan Kiszka
2026-02-02 12:12 ` Andrew Cooper
2026-02-02 13:50 ` Jan Kiszka
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
2026-02-06 0:10 ` Sohil Mehta
2026-02-06 9:23 ` Shashank Balaji
2026-02-13 7:39 ` Shashank Balaji
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e5ac3272-795b-488c-b767-290fd50f2105@intel.com \
--to=sohil.mehta@intel.com \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.makhalov@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=daniel.palmer@sony.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=jailhouse-dev@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=jgross@suse.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rahul.bukte@sony.com \
--cc=shashank.mahadasyam@sony.com \
--cc=stable@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@kernel.org \
--cc=tim.bird@sony.com \
--cc=virtualization@lists.linux.dev \
--cc=vkuznets@redhat.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox