From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493Ab2LQRQG (ORCPT ); Mon, 17 Dec 2012 12:16:06 -0500 Received: from mga01.intel.com ([192.55.52.88]:24182 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590Ab2LQRQE (ORCPT ); Mon, 17 Dec 2012 12:16:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,303,1355126400"; d="scan'208";a="265545263" Message-ID: <50CF5348.2000606@linux.intel.com> Date: Mon, 17 Dec 2012 09:15:52 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jan Beulich CC: Arnd Bergmann , Ingo Molnar , Michael Kerrisk , Guennadi Liakhovetski , Matt Fleming , Thomas Gleixner , Linus Torvalds , "Paul E. McKenney" , Dave Jones , David Howells , Grant Likely , Markus Trippelsdorf , Linux Kernel Mailing List Subject: Re: [GIT PULL] x86/uapi for 3.8 References: <201212122211.qBCMBRxl027895@terminus.zytor.com> <23916.1355356085@warthog.procyon.org.uk> <21507.1355528749@warthog.procyon.org.uk> <20121215163323.GA229@x4> <50CEEE3302000078000B0AC0@nat28.tlf.novell.com> <50CF4FC502000078000B0CB6@nat28.tlf.novell.com> <50CF4ACD.80701@linux.intel.com> <50CF5E8602000078000B0D2C@nat28.tlf.novell.com> In-Reply-To: <50CF5E8602000078000B0D2C@nat28.tlf.novell.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/17/2012 09:03 AM, Jan Beulich wrote: >>>> On 17.12.12 at 17:39, "H. Peter Anvin" wrote: >> Right, I think you nailed this one. This patch copies PTEs from the >> kernel PTEs and thus they will have the global bit set. It obviously >> makes no sense to *copy* PTEs from the kernel and yet leaving the global >> bit set, which means there are two ways of fixing it: either sharing >> page tables and use the cr4.pge off/on trick that Jan mentioned -- this >> would also be my preference -- and the other is to copy the PTEs but >> strip the global bit, which has the advantage that the actual kernel >> mappings will survive. > > PTE copying is only one half of it. I think additionally L4 entries > get copied for the 1:1 mapping, and you can't strip the global > bits there without allocating separate page tables. > The point right now is that it *does* allocate separate page tables, but doesn't take advantage of it. What I say is I think we should take the flush for the advantage of sharing page tables. If we are allocating new page tables then we should of course make them non-global. Do we know how often this gets called? I presume the most common case is when we have an EFI RTC? Unless there is a use case where this happens a lot sharing seems much easier... -hpa