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
relocate_kernel_64.S:
/*
* 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?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
