[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5ac3272-795b-488c-b767-290fd50f2105@intel.com>
Date: Thu, 5 Feb 2026 15:18:58 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Shashank Balaji <shashank.mahadasyam@...y.com>
CC: Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
<x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Suresh Siddha
<suresh.b.siddha@...el.com>, "K. Y. Srinivasan" <kys@...rosoft.com>, "Haiyang
Zhang" <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
<decui@...rosoft.com>, Long Li <longli@...rosoft.com>, Ajay Kaher
<ajay.kaher@...adcom.com>, Alexey Makhalov <alexey.makhalov@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Jan Kiszka <jan.kiszka@...mens.com>, Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>, Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, Ingo Molnar <mingo@...e.hu>,
<linux-kernel@...r.kernel.org>, <linux-hyperv@...r.kernel.org>,
<virtualization@...ts.linux.dev>, <jailhouse-dev@...glegroups.com>,
<kvm@...r.kernel.org>, <xen-devel@...ts.xenproject.org>, Rahul Bukte
<rahul.bukte@...y.com>, Daniel Palmer <daniel.palmer@...y.com>, Tim Bird
<tim.bird@...y.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel
expects so
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
Powered by blists - more mailing lists