WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PAE issue (32-on-64 work)

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] PAE issue (32-on-64 work)
From: Joe Bonasera <joe.bonasera@xxxxxxx>
Date: Thu, 19 Oct 2006 09:19:17 -0700
Delivery-date: Thu, 19 Oct 2006 09:19:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E1GaYNL-0000rc-Ub@host-192-168-0-1-bcn-london>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1GaYNL-0000rc-Ub@host-192-168-0-1-bcn-london>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414

Date: Thu, 19 Oct 2006 13:56:51 +0100
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] PAE issue (32-on-64 work)
To: Jan Beulich <jbeulich@xxxxxxxxxx>,    <xen-devel@xxxxxxxxxxxxxxxxxxx>
Message-ID: <C15D34A3.2CB1%Keir.Fraser@xxxxxxxxxxxx>
Content-Type: text/plain;       charset="US-ASCII"

On 19/10/06 11:39, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:


Just now I found that there is a resulting issue for the 32on64 work I'm
doing: Since none of the entries 4...511 of the PMD get initialized in Linux,
and since Xen nevertheless has to validate all 512 entries (in order to
avoid making available translations that could be used during speculative
execution), the validation has the potential to fail (and does in reality),
resulting in the guest dying. The only option I presently see is to special
case the compatibility guest in the l3 handling and (I really hate to do
that) clear out the 518 supposedly unused entries (or at least clear
their present bits), meaning that no guest may ever make clever
assumptions and try to store some other data in the unused portion of
the pgd page.


Either copy the PGDs out into a shadow L3, as we do for PAE Xen today. Or,
as you say, zap the 508 unused entries. No guest uses them -- I'm pretty
sure Linux is the only PAE-capable guest (others are non-pae or 64-bit).
Storing other stuff in the page would be inconvenient anyway since it has to
be read-only.

 -- Keir


I just now happen to be changing the Solaris 32 bit domains to support
PAE on XEN, purposely to be able to use the 32-on-64 capabilites as they are
available.

The code path in Solaris currently supports 2 possibilities for PAE top level
tables. The normal code we use on bare metal allocates only 1 page
that all cpu's share for the the top level page table. For
example, cpu0 uses the 1st four quads for its current process'
L3, cpu1 uses the next four, etc. On context switch or cr3 reload
we (re)copy in the 4 entries of the process for that CPU's section
of the page.

That code path is, as so much of the 32 bit PAE support, a special
case. So it was easily turned off and made to just use
an entire page for each unique top level L3 on Xen.  I did that just for
my initial bring up on PAE Xen, but was hoping to go back to some
form of the optimized version next.

Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel