From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Allocate vmcs pages when system booting Date: Thu, 12 Nov 2009 11:22:44 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jiang, Yunhong" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 12/11/2009 10:52, "Jiang, Yunhong" 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 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? -- Keir