All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Sneddon <daniel.sneddon@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "Shutemov, Kirill" <kirill.shutemov@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, "Gomez Iglesias,
	Antonio" <antonio.gomez.iglesias@intel.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Subject: Re: [PATCH] x86/apic: Don't disable x2APIC if locked
Date: Wed, 10 Aug 2022 13:06:50 -0700	[thread overview]
Message-ID: <2446fb33-9c5c-642a-797e-4e93345adb82@linux.intel.com> (raw)
In-Reply-To: <d315aac4-8cda-bc2d-d052-09fb0649b1ad@intel.com>

On 8/10/22 12:59, Dave Hansen wrote:
> On 8/10/22 12:40, Daniel Sneddon wrote:
>>> It it going to be *forced* on those SPR system?  In other words, is it a
>>> little BIOS switch that users can flip?  Is there any non-kernel
>>> workaround if a user hits this, or is the entire burden of this going to
>>> be foisted on the kernel?
>> It won't be forced, BUT, certain features won't be available if the APIC isn't
>> locked.  According to the documentation SGX and TDX won't be available if you
>> don't lock the APIC.  So, yes, you don't have to fix it in the kernel, but you
>> may lose access to features if you don't.
> 
> Let's get some of this in the changelog and _possibly_ Documentation/ so
> that users know we're depending on the BIOS to play nice.  Let's put
> ourselves in the place of our users for a moment at least and try to
> figure out how we play our part to help get them from seeing "can't
> disable x2apic mode" or whatever to them flipping knobs in the BIOS.

I will certainly add this to the changelog.  I could add a blurb to the
documentation where nox2apic is defined as a parameter as well.  If there is a
better place to document that please let me know.

> 
> I also dearly hope that Intel has told BIOS writers that the onus is on
> them *and* those nice BIOS folks listen to Intel. :)
You and me both!  I know this has gone out to our BIOS partners and they are
aware of it.  Beyond that, well, I guess we'll find out when SPR is released!

> 
> In any case, I don't think backports are warranted here at the moment.
> We can always do it in the future if the need arises.


  reply	other threads:[~2022-08-10 20:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 23:40 [PATCH] x86/apic: Don't disable x2APIC if locked Daniel Sneddon
2022-08-10 18:01 ` Dave Hansen
2022-08-10 18:30   ` Daniel Sneddon
2022-08-10 18:52     ` Dave Hansen
2022-08-10 19:40       ` Daniel Sneddon
2022-08-10 19:59         ` Dave Hansen
2022-08-10 20:06           ` Daniel Sneddon [this message]
2022-08-10 20:29             ` Daniel Sneddon
2022-08-10 21:57               ` Dave Hansen
2022-08-10 22:06         ` Thomas Gleixner
2022-08-10 22:56           ` Daniel Sneddon
2022-08-10 23:03           ` Daniel Sneddon
2022-08-10 23:09             ` Dave Hansen
2022-08-10 23:38               ` Daniel Sneddon
2022-08-10 23:44                 ` Dave Hansen
2022-08-11  0:01                   ` Daniel Sneddon
2022-08-11  0:38                     ` Thomas Gleixner
2022-08-11  0:59                       ` Daniel Sneddon
2022-08-11 10:08                         ` Huang, Kai
2022-08-11  0:17                 ` Thomas Gleixner
2022-08-11  0:40                   ` Daniel Sneddon
2022-08-11  8:29               ` Huang, Kai

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=2446fb33-9c5c-642a-797e-4e93345adb82@linux.intel.com \
    --to=daniel.sneddon@linux.intel.com \
    --cc=antonio.gomez.iglesias@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.