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] RE: [PATCH] Allocate vmcs pages when system booting

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] Allocate vmcs pages when system booting
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 12 Nov 2009 22:58:58 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Thu, 12 Nov 2009 06:59:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C721A084.19F5B%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E2263E4A5B2284449EEBD0AAB751098418E5557546@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C721A084.19F5B%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acpjhi/FowWYJHS9QX+XJREOh9n85gABERxSAAcM60A=
Thread-topic: [PATCH] Allocate vmcs pages when system booting

Keir Fraser wrote:
> On 12/11/2009 10:52, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>> Currently the VMCS page is allocated when the CPU is brought-up and
>> identified, and then spin_debug_enable() is called.
>> This does not work for cpu hot-add. When hot-added CPU is brought-up
>> and try to allocate the vmcs page, it will hit check_lock, because
>> irq is disabled still. 
>> This patch allocate the vmcs pages for all possible pages when
>> system booting, so that we don't allocate vmcs anymore when
>> secondary CPU is up. 
>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
> A general point: using cpu_possible_map is not a good idea any
> longer, since it is going to be all-ones as soon as your physical cpu
> hotplug patches go
> in (I don't intend to make that a build-time option). Hence we could
> potentially massively over-allocate pages with this approach.
> The good news is that, when bringing a CPU online, we don't
> need to worry
> about acquiring IRQ-unsafe locks with IRQS disabled until the
> CPU is added
> to the cpu_online_map. This is because the race we are trying
> to avoid with
> the spin-debug checks involves rendezvous of CPUs via IPIs,
> and a CPU not in
> cpu_online_map will never get waited on by others.
> So, your better fix would be to spin_debug_disable() at the top of
> start_secondary(), and spin_debug_enable() just before
> cpu_set(...online_map). 
> Can you try this alternative fix please?

Yes, spin_debug_disable() is the first idea come into my mind, I change my mind 
because the spin_debug is a global variable.  disable spin_debug() before 
start_secondary means maybe we can't catch error happens at that window, so I 
choose this method. Previously I thought high-end system support cpu hotplug 
may not care about the 64 pages :$

Or you assume this window is quite small, and we can assume safely if a error 
happening at this window, it will happen in other timeslot in the end, 
sepecially this function itself don't need the check?

Yunhong Jiang

> -- Keir
Xen-devel mailing list