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

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

  • To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Thu, 19 Oct 2006 12:03:45 +0100
  • Delivery-date: Thu, 19 Oct 2006 04:04:26 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acbzav4LuIdQ54/2SFWLg7WjbcE2VgAAp4dw
  • Thread-topic: [Xen-devel] PAE issue (32-on-64 work)

> As I had expressed before, I'm thinking that the current way of
> the
> top level of PAE paging is inappropriate, even after the above-4G
> adjustments
> that cured part of the problem. This is specifically because
> - the handling here isn't consistent with how hardware behaves in the
> situation (though the Xen behavior is probably within range of the
> architecture specification), in that the processor reads the 4 top
> entries
> when CR3 gets re-loaded (and hence doesn't try to access them later in
> way), while Xen treats them (including potential updates to them) like
> on any level in the hierarchy
> - the guest still needs to allocate a full page, even though only the
> 32
> bytes of it are actually used
> - the shadowing done in Xen could be avoided altogether by following
> hardware behavior.
> Just now I found that there is a resulting issue for the 32on64 work
> 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
> avoid making available translations that could be used during
> execution), the validation has the potential to fail (and does in
> resulting in the guest dying. The only option I presently see is to
> case the compatibility guest in the l3 handling and (I really hate to
> 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.

Why not just have a fixed per-vcpu L4 and L3, into which the 4 PAE L3's
get copied on every cr3 load?
It's most analogous to what happens today.  

We've thought of removing the page-size restriction on PAE L3's in the
past, but it's pretty low down the priority list as it typically doesn't
cost a great deal of memory.


Xen-devel mailing list



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