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
> 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?
> -- Keir
Xen-devel mailing list