![]() | |||||||||||||
Messages in this thread |
Jeremy Fitzhardinge wrote: >> >> What is the e820 information you feed the kernel? We should only ever >> allocate page tables out of available RAM, not any other type of >> memory (reserved or not). > > The kernel gets a flat memory map; all memory is just plain RAM. The > problem is that we're allocating a normal page and turning it into a > pagetable - so far so good. Then the DMI code is randomly mapping that > same page RW so it can scan it for DMI signatures, which Xen is preventing. > > There are two immediate fixes: > > 1. Only scan for DMI if the memory is reserved (rejected, because HPA > says some machines don't reserve the DMI space). Alternatively, > don't bother scanning if booting under Xen. > 2. Make DMI map the memory RO so that Xen doesn't complain (which is > sensible because DMI is ROM anyway). > > But as far as I can tell, this shouldn't be happening anyway, and could > happen on real hardware which doesn't reserve the DMI space. It > probably doesn't because initial pagetables on real hardware use large > pages, and therefore allocate less memory for pagetable memory and > therefore doesn't end up hitting the 0xf0000 region. But that area > should be excluded from the allocation pool. > 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. However, Xen may want to consider why provide memory below the 1 MB point at all, and certainly whether it's wise to provide RAM in the 640-1024 KB legacy region -- although you could argue that "it *should* work", odds are pretty good you'll have nasty surprises on a regular basis. -hpa | ||||||||||||
| Last update: 2008-02-22 00:21 [W:0.719 / U:0.280 seconds] ©2003-2008 Jasper Spaans | |||||||||||||