[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.