[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVCJo8dNBnEA2p3dhgymfcfMN=uhMz0XXn047=tsQNnFw@mail.gmail.com>
Date: Wed, 21 Jun 2017 13:34:10 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Nadav Amit <nadav.amit@...il.com>,
Rik van Riel <riel@...hat.com>,
Dave Hansen <dave.hansen@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems
On Wed, Jun 21, 2017 at 2:39 AM, Thomas Gleixner <tglx@...utronix.de> 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?
Powered by blists - more mailing lists