OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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>
This commit is contained in:
Andy Lutomirski 2017-09-06 19:54:54 -07:00 committed by Linus Torvalds
parent 72c0098d92
commit 1c9fe4409c
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
arch/x86/kernel/cpu/common.c
View File

@ -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 {
/*