On Fri, 2008-02-22 at 07:25 +0000, Ian Campbell wrote: > On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote: > > > > Which it is on real hardware, because although it's not *reserved* > > (type 2), it is certainly not made available as *normal memory* (type > > 1). If Xen maps this as type 1 then I definitely see the problem. > > > > We can exclude type 1 memory from DMI scan, certainly. > > I'd been meaning to ask this. So the machines you have which don't > describe 0xf0000 as reserved also don't describe it as RAM? (I guess > it's either a hole in the table or one of the other e820 types). > Ian.
... > >From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001 > From: Ian Campbell <[EMAIL PROTECTED]> > Date: Fri, 22 Feb 2008 07:17:14 +0000 > Subject: [PATCH] x86: Do not scan for DMI if the DMI region is marked as RAM > by e820. > > Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain > a > page table and hence cannot be mapped. The e820 map given to guest reflects > this. > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]> ... > @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void) > } > } > else { > + if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM)) > + goto out; One issue with using the e820 map for this is that a Xen Dom0 will also have this region marked as RAM in the e820 map, but will set up a fixmap for it, allowing dmi_scan_machine() to map the region. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/