[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 |