[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 8/8] 2.6.17: scan DMI early

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 05 Mar 2007 15:51:54 +0000
  • Delivery-date: Mon, 05 Mar 2007 07:51:59 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdfPjJPcKaLS8sxEdu3zwAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH 8/8] 2.6.17: scan DMI early

On 14/2/07 16:00, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> While shuffling quite a few things around, this gets us closer to native,
> which clearly had a reason to do the DMI scan early.
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

Taken, but a few comments:

 - could we get rid of alloc_static_page() and use spp_getpage() everywhere?

 - the double-staged find_early_table_space(), where table_end gets updated
halfway through init_memory_mapping(), is pretty skanky. I suppose we get to
keep the BUG_ON(start_pfn != table_end) this way, but perhaps it would be
nicer just to set table_end once and for all in find_early_table_space().

 - the estimate of number of fixmap pagetables required in
find_early_table_space() is conservative. Is there any risk that
spp_getpage() may end up with start_pfn<table_end for long enough that we
run into concurrency issues? Perhaps we could do a dummy set_fixmap for
every fixmap slot to force population of all fixmap slots in
init_memory_mapping(), and then BUG_ON(start_pfn != table_end)?

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.