Messages in this thread | | | Subject | Re: [PATCH]Fix broken VMI in 2.6.27-rc.. | From | Zachary Amsden <> | Date | Thu, 07 Aug 2008 14:27:18 -0700 |
| |
On Thu, 2008-08-07 at 14:20 -0700, H. Peter Anvin wrote: > Alok Kataria wrote: > > > > VMI relies on relocating the fixmap area to make room for the > > hypervisor. These 2 commits started accessing the fixmap area's and > > using them before VMI got a chance to check if it wants to relocate the > > fixmap area. Once VMI got to the point of relocating the fixmap area's > > it resulted in BUG's. > > > > Could you describe this in more detail? I am not super-happy about this > solution if there is a better one, like simply locating the fixmap area > out of the way to start with.
That can't be done until we know the size of the hole to relocate, which isn't known until we probe in the first meg of memory to find the associated ROM. It used to be the case that other things that poked around with platform specific memory and checking ROM areas lived around here in setup.c, so it was a nice place to put it. With all the abstraction and combination and overifdeffing going on here, that might no longer be the case.
We could move it earlier, but then we'd need another hook to call in after max_low_pfn is known.
Or we could remove the dependency on max_low_pfn and just create a liberal linear to physical mapping for lomem which spans all possible low memory; then it doesn't matter so much where it is called.
Zach
| |