[PATCH 0/8] 2.6.17 merge additions

[PATCH 0/8] 2.6.17 merge additions

[Jan Beulich]

Following will be a set of patches that adjust 2.6.17 merges we had done
differently in our internal tree, and that I think shouldn't get lost. There
is no particular ordering among them, so if any seems questionable, others
can still be applied.

Jan

Re: [PATCH 0/8] 2.6.17 merge additions

[Jan Beulich]

>>> "Jan Beulich" <jbeulich@novell.com> 14.02.07 16:56 >>>
>Following will be a set of patches that adjust 2.6.17 merges we had done
>differently in our internal tree, and that I think shouldn't get lost. There
>is no particular ordering among them, so if any seems questionable, others
>can still be applied.

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?

Thanks, Jan

Re: [PATCH 0/8] 2.6.17 merge additions

[Keir Fraser]

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
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.

 -- Keir

Re: [PATCH 0/8] 2.6.17 merge additions

[Jan Beulich]

>>> 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

Re: [PATCH 0/8] 2.6.17 merge additions

[Keir Fraser]

On 2/3/07 09:59, "Jan Beulich" <jbeulich@novell.com> wrote:

> 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.

Okay I probably should have done a three-way comparison with the native code
as well, then. My first impression was definitely that the code looked more
complicated rather than less. :-) I'll take another look.

 -- Keir