From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: understanding __linear_l2_table and friends Date: Thu, 21 Apr 2005 21:42:16 +0200 Message-ID: <20050421194216.GB13678@bytesex> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com, Ian Pratt , ak@suse.de, Scott Parish List-Id: xen-devel@lists.xenproject.org > The alternative is to hack PAE Linux to force the L2 containing kernel > mappings to be per-pagetable rather than shared. The downside of the is > that we use an extra 4KB per pagetable, and have the hassle of faulting > in kernel L2 mappings on demand (like non-PAE Linux has to). This plays > nicely with the TLB flush filter, and is fine for SMP guests. I think that one is better. The topmost L2 table with the kernel mappings is a special case anyway because it also has the hypervisor hole and thus differs from the other three L2 tables when it comes to allocation and verification (and maybe other places as well). I'm considering adding a new page type for the topmost L2 in PAE mode to handle this. Comments? Better ideas? Gerd -- #define printk(args...) fprintf(stderr, ## args)