[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <50CF5E8602000078000B0D2C@nat28.tlf.novell.com>
Date: Mon, 17 Dec 2012 17:03:50 +0000
From: "Jan Beulich" <JBeulich@...e.com>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
Cc: "Arnd Bergmann" <arnd@...db.de>, "Ingo Molnar" <mingo@...e.hu>,
"Michael Kerrisk" <mtk.manpages@...il.com>,
"Guennadi Liakhovetski" <g.liakhovetski@....de>,
"Matt Fleming" <matt.fleming@...el.com>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"Dave Jones" <davej@...hat.com>,
"David Howells" <dhowells@...hat.com>,
"Grant Likely" <grant.likely@...retlab.ca>,
"Markus Trippelsdorf" <markus@...ppelsdorf.de>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/uapi for 3.8
>>> On 17.12.12 at 17:39, "H. Peter Anvin" <hpa@...ux.intel.com> 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.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists