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

Re: [Xen-devel] x86-64's paging_init()


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 31 Aug 2006 18:58:28 +0100
  • Delivery-date: Thu, 31 Aug 2006 10:58:42 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbM4M8Ue5ysa9FaR4iyG6lfuX1SXwARkDFN
  • Thread-topic: [Xen-devel] x86-64's paging_init()

Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or
allocate-and-map the new l2 in that same function (but raises question of
how to test the new code path).

 -- Keir

On 31/8/06 10:34 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> While adding code to create the compatibility p2m table mappings it
> seemed
> to me that the creation of the native ones is restricted to memory below
> the 512G boundary - otherwise, additional L2 tables would need to be
> allocated (currently other memory following the one L2 page getting
> allocated would be blindly overwritten). While I realize that machines
> this
> big aren't likely to be targeted by Xen at this point anyway (although
> the
> direct map area explicitly provides for 1T), I'd still want this fixed
> if
> someone confirms I'm not mis-reading something here (of if that's the
> case,
> then I'd still need a good explanation, as then I'm likely screwing up
> the
> compatibility table creation).



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


 


Rackspace

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