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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 thisI''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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel