Re: [PATCH]Fix broken VMI in 2.6.27-rc..

From: Alok Kataria
Date: Thu Aug 07 2008 - 17:41:25 EST


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/