Re: [PATCH 0/8] 2.6.17 merge additions

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir@xensource.com> 02.03.07 10:19 >>>
>On 2/3/07 09:05, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> Before submitting 2.6.18 stuff we were missing from the -unstable merge,
>> is it possible to get an understanding why patches 5 (pc speaker device
>> registration in domU) and 8 (early DMI scan) of the 2.6.17 set were not
>> taken?
>
>I'm undecided on those. Keeping pcspkr is pretty harmless (actually I'm not
>sure what the device registration is even for!) and removing it would just
>take us further from native. I don't have a really strong opinion on this

I'm not certain on this one either, as (like you) I'm not entirely clear what
the consequences of registering this is without a real device underneath.
Clearly, drivers/input/misc/pcspkr.c can be prevented from trying to play
with port 61 (and registering an unusable input device) by not registering
this device.

>one however. For the second patch: the principle of moving DMI scan earlier
>is nice, but this approach makes a horrible mess of the mm init code (which
>is quite nasty enough already!). I wonder whether we could come up with a
>two-stage mm init for x86/64 -- some very early Xen-specific stuff to get is
>into a state that is a bit more like native, would allow us to do things
>like DMI scan at a more appropriate time, and might clean up the
>paging_init() mess a bit rather than making it worse.

Isn't that patch just doing this -  paging_init() is almost identical to native
after the patch (the sole difference is the setting of init_mm.context.pinned).
The only real addition (to find_early_table_space()) is the space reservation
for the fixmap tables (so these can be set up earlier) and the stuff moved
out of paging_init() into init_memory_mapping(). And I don't think it is
reasonable to expect init_memory_mapping() to get very close to native.

Jan