Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems

From: Andy Lutomirski
Date: Wed Jun 21 2017 - 16:34:43 EST

On Wed, Jun 21, 2017 at 2:39 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Tue, 20 Jun 2017, Andy Lutomirski wrote:
>> + /* Set up PCID */
>> + if (cpu_has(c, X86_FEATURE_PCID)) {
>> + if (cpu_has(c, X86_FEATURE_PGE)) {
>> + cr4_set_bits(X86_CR4_PCIDE);
> So I assume that you made sure that the PCID bits in CR3 are zero under all
> circumstances as setting PCIDE would cause a #GP if not.

Yes. All existing code just shoves a PA of a page table in there. As
far as I know, neither Linux nor anyone else uses the silly PCD and
PWT bits. It's not even clear to me that they are functional if PAT
is enabled.

> And what happens on kexec etc? We need to reset the asid and PCIDE I assume.

I assume it works roughly the same way as suspend, etc --
mmu_cr4_features has the desired CR4 and the init code deals with it.
And PGE, PKE, etc all work correctly. I'm not sure why PCIDE needs to
be cleared -- the init code will work just fine even if PCIDE is
unexpectedly set.

That being said, I haven't managed to understand what exactly the
kexec code is doing. But I think the relevant bit is here in

* Set cr4 to a known state:
* - physical address extension enabled
movl $X86_CR4_PAE, %eax
movq %rax, %cr4

Kexec folks, is it safe to assume that kexec can already deal with the
new and old kernels disagreeing on what CR4 should be?