Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751620AbdFUUee (ORCPT ); Wed, 21 Jun 2017 16:34:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:33616 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750827AbdFUUed (ORCPT ); Wed, 21 Jun 2017 16:34:33 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 003F321D2C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: <57c1d18b1c11f9bc9a3bcf8bdee38033415e1a13.1498022414.git.luto@kernel.org> From: Andy Lutomirski Date: Wed, 21 Jun 2017 13:34:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems To: Thomas Gleixner Cc: Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" , Nadav Amit , Rik van Riel , Dave Hansen , Arjan van de Ven , Peter Zijlstra , Juergen Gross , Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1478 Lines: 38 On Wed, Jun 21, 2017 at 2:39 AM, Thomas Gleixner 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?