Messages in this thread | | | Subject | Re: [PATCH]Fix broken VMI in 2.6.27-rc.. | From | Alok Kataria <> | Date | Thu, 07 Aug 2008 14:41:05 -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?
Hi Peter,
The first commit, x86: use acpi_numa_init to parse on 32-bit numa commit 1c6e55032e24ff79668581a0f296c278ef7edd4e
Moves the call to dmi_scan_machine before the vmi_initialization is done, dmi_scan_machine internally calls early_ioremap, which does early_set_fixmap effectively making use of FIXMAP areas before VMI gets a chance to relocate it.
Similarly, in the other commit, x86: move fix mapping page table range early commit e7b3789524eecc96213dd69d6686efd429235051
There is this new call to early_ioremap_page_table_range_init which is done from init_memory_mapping, this uses FIXADDR_TOP to initialize the page table range.
Now if you look at vmi_init, we relocate the fixmap area by changing the __FIXADDR_TOP value. So this needs to happen before anybody starts using the fixmap area.
> 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.
I won't say that i completely understand this statement , but IMO the patch that i sent effectively does the same thing, we make sure that the fixmap area is set to a final value before anybody else starts using it.
Thanks, Alok > > -hpa
| |