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: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 40cb4d0a59820ca6388c877ea1c9d599585409d0..fb1d3358a4af5bde82e5d8dd751b2db3271a2c82 100644 (file)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.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_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);
                } else {
                        /*