Received: by 10.213.65.68 with SMTP id h4csp886646imn; Wed, 4 Apr 2018 08:54:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx49CpLPmTdxrJb6ai1nlcIpkF6zRcBA1DZx5IWf2dSyoLzmjnlrphwTSCd+7jh/bqgVJ2DHO X-Received: by 2002:a17:902:ba8a:: with SMTP id k10-v6mr19166333pls.337.1522857275899; Wed, 04 Apr 2018 08:54:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522857275; cv=none; d=google.com; s=arc-20160816; b=GcbfsHSouzob/tjo3QJFYyfNshLnEbz05Z22ykurAHxrA9jovqUzdfgCq7uhZQjqtY bN2eoMrV85sAZwlo2UexLA2LZTFAuQhdliX5BtU2rL7ZHRVtNYP7DmMOnOqG98saFpr+ s7jsAdSLzR6iXViqA22DWOSgGqWvCX5WxXs07bq8F04wVY/wdtZoXlEAXhLDxZsyVYg6 3U/MsAfAE/4bNppz3/3tO6dUuFyqwof0NsZbGnXXEJgEm+SDr0BWw3qpkFdsBjq7ZhvC j3npFAx8Lvd2VLLFknfMlSn4HMRn2PGd2g07GSfqzGNrwUXDhYtz4BKjgh9iysAQG9PR 5uOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=Mu/bgVGTkeHkz5EFe17gGbmE6Wc76gIj4cI+eDyKbXs=; b=uGs564597tCw0p9KKmCM4yoDvlPRr/IuIW5CRIFKHAdEiZ/pCimQEEXO2a+l4x3shb g1IMUnk+laCYYUosD9SO5lD/CF4AFuVpmRqB84xnQ2bJVz6C5ZuRKM9xfbD0azJ7wdia 8gVFgRN9fJ9JXOzALttTjS/v1sK/jATHiLGfxb9JFiHw79MtjTVuKUA6dxfI1F7sXFnI QRdYOjkJ202TcSdfZ4N/si6BuDaj6U3/kuKeBrwza2RJxm9jlw4aOhL5CkrcsJeY2t/I fCOSVlrB+9k/LgDLbLJbz9vZHhJI3sbtmVZO9WLdTHEp9NvVr/PvsTfBzlfpvjH6jmmf HUEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 76si3852776pgd.712.2018.04.04.08.54.21; Wed, 04 Apr 2018 08:54:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752239AbeDDPwk (ORCPT + 99 others); Wed, 4 Apr 2018 11:52:40 -0400 Received: from mga03.intel.com ([134.134.136.65]:9896 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752202AbeDDPwi (ORCPT ); Wed, 4 Apr 2018 11:52:38 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 08:52:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,407,1517904000"; d="scan'208";a="188623060" Received: from ray.jf.intel.com (HELO [10.7.201.20]) ([10.7.201.20]) by orsmga004.jf.intel.com with ESMTP; 04 Apr 2018 08:52:37 -0700 Subject: Re: [PATCH 09/11] x86/pti: enable global pages for shared areas To: Nadav Amit References: <20180404010946.6186729B@viggo.jf.intel.com> <20180404011007.A381CC8A@viggo.jf.intel.com> <5DEE9F6E-535C-4DBF-A513-69D9FD5C0235@vmware.com> Cc: LKML , "open list:MEMORY MANAGEMENT" , Andrea Arcangeli , Andy Lutomirski , Linus Torvalds , "keescook@google.com" , Hugh Dickins , Juergen Gross , "x86@kernel.org" From: Dave Hansen Message-ID: <50385d91-58a9-4b14-06bc-2340b99933c3@linux.intel.com> Date: Wed, 4 Apr 2018 08:52:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5DEE9F6E-535C-4DBF-A513-69D9FD5C0235@vmware.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/03/2018 09:45 PM, Nadav Amit wrote: > Dave Hansen wrote: > >> >> From: Dave Hansen >> >> The entry/exit text and cpu_entry_area are mapped into userspace and >> the kernel. But, they are not _PAGE_GLOBAL. This creates unnecessary >> TLB misses. >> >> Add the _PAGE_GLOBAL flag for these areas. >> >> Signed-off-by: Dave Hansen >> Cc: Andrea Arcangeli >> Cc: Andy Lutomirski >> Cc: Linus Torvalds >> Cc: Kees Cook >> Cc: Hugh Dickins >> Cc: Juergen Gross >> Cc: x86@kernel.org >> Cc: Nadav Amit >> --- >> >> b/arch/x86/mm/cpu_entry_area.c | 10 +++++++++- >> b/arch/x86/mm/pti.c | 14 +++++++++++++- >> 2 files changed, 22 insertions(+), 2 deletions(-) >> >> diff -puN arch/x86/mm/cpu_entry_area.c~kpti-why-no-global arch/x86/mm/cpu_entry_area.c >> --- a/arch/x86/mm/cpu_entry_area.c~kpti-why-no-global 2018-04-02 16:41:17.157605167 -0700 >> +++ b/arch/x86/mm/cpu_entry_area.c 2018-04-02 16:41:17.162605167 -0700 >> @@ -27,8 +27,16 @@ EXPORT_SYMBOL(get_cpu_entry_area); >> void cea_set_pte(void *cea_vaddr, phys_addr_t pa, pgprot_t flags) >> { >> unsigned long va = (unsigned long) cea_vaddr; >> + pte_t pte = pfn_pte(pa >> PAGE_SHIFT, flags); >> >> - set_pte_vaddr(va, pfn_pte(pa >> PAGE_SHIFT, flags)); >> + /* >> + * The cpu_entry_area is shared between the user and kernel >> + * page tables. All of its ptes can safely be global. >> + */ >> + if (boot_cpu_has(X86_FEATURE_PGE)) >> + pte = pte_set_flags(pte, _PAGE_GLOBAL); > > I think it would be safer to check that the PTE is indeed present before > setting _PAGE_GLOBAL. For example, percpu_setup_debug_store() sets PAGE_NONE > for non-present entries. In this case, since PAGE_NONE and PAGE_GLOBAL use > the same bit, everything would be fine, but it might cause bugs one day. That's a reasonable safety thing to add, I think. But, looking at it, I am wondering why we did this in percpu_setup_debug_store(): for (; npages; npages--, cea += PAGE_SIZE) cea_set_pte(cea, 0, PAGE_NONE); Did we really want that to be PAGE_NONE, or was it supposed to create a PTE that returns true for pte_none()? >> /* >> + * Setting 'target_pmd' below creates a mapping in both >> + * the user and kernel page tables. It is effectively >> + * global, so set it as global in both copies. Note: >> + * the X86_FEATURE_PGE check is not _required_ because >> + * the CPU ignores _PAGE_GLOBAL when PGE is not >> + * supported. The check keeps consistentency with >> + * code that only set this bit when supported. >> + */ >> + if (boot_cpu_has(X86_FEATURE_PGE)) >> + *pmd = pmd_set_flags(*pmd, _PAGE_GLOBAL); > > Same here. Is there a reason that the pmd_none() check above this does not work?