From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 0/8] 2.6.17 merge additions Date: Fri, 02 Mar 2007 09:59:31 +0000 Message-ID: <45E80393.76E4.0078.0@novell.com> References: <45E7F701.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 02.03.07 10:19 >>> >On 2/3/07 09:05, "Jan Beulich" 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