Commit 1c9fe440 authored by Andy Lutomirski's avatar Andy Lutomirski Committed by Linus Torvalds

x86/mm: Document how CR4.PCIDE restore works

While debugging a problem, I thought that using
cr4_set_bits_and_update_boot() to restore CR4.PCIDE would be
helpful.  It turns out to be counterproductive.

Add a comment documenting how this works.
Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 72c0098d
...@@ -333,6 +333,19 @@ static void setup_pcid(struct cpuinfo_x86 *c) ...@@ -333,6 +333,19 @@ static void setup_pcid(struct cpuinfo_x86 *c)
{ {
if (cpu_has(c, X86_FEATURE_PCID)) { if (cpu_has(c, X86_FEATURE_PCID)) {
if (cpu_has(c, X86_FEATURE_PGE)) { if (cpu_has(c, X86_FEATURE_PGE)) {
/*
* We'd like to use cr4_set_bits_and_update_boot(),
* but we can't. CR4.PCIDE is special and can only
* be set in long mode, and the early CPU init code
* doesn't know this and would try to restore CR4.PCIDE
* prior to entering long mode.
*
* Instead, we rely on the fact that hotplug, resume,
* etc all fully restore CR4 before they write anything
* that could have nonzero PCID bits to CR3. CR4.PCIDE
* has no effect on the page tables themselves, so we
* don't need it to be restored early.
*/
cr4_set_bits(X86_CR4_PCIDE); cr4_set_bits(X86_CR4_PCIDE);
} else { } else {
/* /*
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment