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


[Xen-devel] changeset 8775

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] changeset 8775
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 08 Feb 2006 10:37:00 +0100
Delivery-date: Wed, 08 Feb 2006 09:47:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
While this changeset appears to finally address the cpu_possible_map problems 
(according to other reports on this list)
I wonder if this isn't incomplete. With prefill_possible_map() now being called 
from setup_arch() (why can't it be
called at the same point as native calls it when CONFIG_HOTPLUG_CPU?), the 
immediately following call to
smp_prepare_boot_cpu() (from start_kernel) will destroy this information again. 
With the effort of not setting up
per-CPU information for impossible CPUs (some of this exists in our internal 
trees, not sure how much has been posted to
mainline) this would be prone to break again soon.
Also, some of other code seems then superfluous or even ill:
- drivers/xen/core/smpboot.c: smp_prepare_cpus() should not initialize 
cpu_possible_map again, but should instead have
its main loop controlled by this bit vector (and VCPUOP_is_up doesn't need to 
be called then anymore, too)
- arch/{i386,x86_64}/kernel/mpparse-xen.c: the setting of num_processors was 
and is completely out of sync with the
real set of VCPUs used; I even wonder what purpose the whole file still serves


Xen-devel mailing list

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