| 
    
 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] 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
 
  | 
  
![]()  | 
            
         Lists.xenproject.org is hosted with RackSpace, monitoring our  |