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 8/8] 2.6.17: scan DMI early

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 8/8] 2.6.17: scan DMI early
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Mon, 05 Mar 2007 15:51:54 +0000
Delivery-date: Mon, 05 Mar 2007 07:51:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45D34049.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdfPjJPcKaLS8sxEdu3zwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH 8/8] 2.6.17: scan DMI early
User-agent: Microsoft-Entourage/
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

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