This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 0/8] 2.6.17 merge additions

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>,"Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/8] 2.6.17 merge additions
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 02 Mar 2007 09:59:31 +0000
Delivery-date: Fri, 02 Mar 2007 01:58:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C20D9C8F.A786%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45E7F701.76E4.0078.0@xxxxxxxxxx> <C20D9C8F.A786%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 02.03.07 10:19 >>>
>On 2/3/07 09:05, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>