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

[Xen-devel] [PATCH] x86: don't map more than the allocated space for fra

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] x86: don't map more than the allocated space for frame_table
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 20 May 2009 14:28:40 +0100
Delivery-date: Wed, 20 May 2009 06:29:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
This is to avoid undue virtual address aliases in case the over-mapped
pages happen to get allocated to a domain, and then get their
cacheability attributes changed.

At once, use 1Gb mappings if possible and reasonable.

Also, make frame_table a 'mostly read' variable. Actually, I don't
really understand why this has to be a variable on x86 at all -
address calculations involving it could be cheaper if this was just
a #define. Perhaps kexec is the only thing that needs this to be a
variable, but if that indeed is the only reason, kexec should define
its own static variable.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

--- 2009-05-19.orig/xen/arch/x86/mm.c   2009-03-27 12:40:19.000000000 +0100
+++ 2009-05-19/xen/arch/x86/mm.c        2009-05-20 12:56:01.000000000 +0200
@@ -154,7 +154,7 @@ static DEFINE_PER_CPU(struct percpu_mm_i
 struct domain *dom_xen, *dom_io;
 
 /* Frame table and its size in pages. */
-struct page_info *frame_table;
+struct page_info *__read_mostly frame_table;
 unsigned long max_page;
 unsigned long total_pages;
 
@@ -186,11 +186,18 @@ void __init init_frametable(void)
     frame_table = (struct page_info *)FRAMETABLE_VIRT_START;
 
     nr_pages  = PFN_UP(max_page * sizeof(*frame_table));
-    page_step = (1 << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
+    page_step = 1 << (cpu_has_page1gb ? L3_PAGETABLE_SHIFT - PAGE_SHIFT
+                                      : L2_PAGETABLE_SHIFT - PAGE_SHIFT);
 
     for ( i = 0; i < nr_pages; i += page_step )
     {
-        mfn = alloc_boot_pages(min(nr_pages - i, page_step), page_step);
+        /*
+         * The hardcoded 4 below is arbitrary - just pick whatever you think
+         * is reasonable to waste as a trade-off for using a large page.
+         */
+        while (nr_pages + 4 - i < page_step)
+            page_step >>= PAGETABLE_ORDER;
+        mfn = alloc_boot_pages(page_step, page_step);
         if ( mfn == 0 )
             panic("Not enough memory for frame table\n");
         map_pages_to_xen(




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

<Prev in Thread] Current Thread [Next in Thread>