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

[Xen-devel] arch_init_memory() change


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Altobelli, David" <david.altobelli@xxxxxx>
  • Date: Fri, 22 Jun 2007 16:28:44 -0000
  • Delivery-date: Fri, 22 Jun 2007 09:27:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ace06mbWQQp4xXv+Rxe5UnP7edz9UQ==
  • Thread-topic: arch_init_memory() change

In xen/arch/x86/mm.c, arch_init_memory() does not follow the same logic
as find_max_pfn().  If a 4k non page aligned E820_RAM entry exists as
the last RAM entry in the e820 map, it will be skipped by
find_max_pfn(), but not by arch_init_memory(), triggering BUG_ON(pfn !=
max_page).

The logic in arch_init_memory() could be changed to mirror
find_max_pfn():
--- xen/arch/x86/mm.c.orig      2007-06-22 10:10:19.000000000 -0500
+++ xen/arch/x86/mm.c   2007-06-22 10:11:39.000000000 -0500
@@ -220,6 +220,8 @@ void arch_init_memory(void)
         /* Every page from cursor to start of next RAM region is I/O.
*/
         rstart_pfn = PFN_UP(e820.map[i].addr);
         rend_pfn   = PFN_DOWN(e820.map[i].addr + e820.map[i].size);
+        if (rstart_pfn >= rend_pfn)
+            continue;
         for ( ; pfn < rstart_pfn; pfn++ )
         {
             BUG_ON(!mfn_valid(pfn));  

But I think this breaks the sharing logic.  It might be better to just
remove the BUG_ON():
--- xen/arch/x86/mm.c.orig      2007-06-22 10:10:19.000000000 -0500
+++ xen/arch/x86/mm.c   2007-06-22 11:20:42.000000000 -0500
@@ -229,7 +229,6 @@ void arch_init_memory(void)
         /* Skip the RAM region. */
         pfn = rend_pfn;
     }
-    BUG_ON(pfn != max_page);

     subarch_init_memory();
 }

_______________________________________________
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®.