]> git.baikalelectronics.ru Git - kernel.git/commit
xen/spinlock: Fix locking path engaging too soon under PVHVM.
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tue, 13 Aug 2013 15:47:21 +0000 (11:47 -0400)
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Mon, 9 Sep 2013 16:06:16 +0000 (12:06 -0400)
commit3c97b569387861ba861cbf24145b9ecdd76685d7
treeafa04e3edf9b99e621593464dd9d1f027b19e4ff
parent5cab2afd4a7c1ad269738f95c87aa266cc7b8041
xen/spinlock: Fix locking path engaging too soon under PVHVM.

The xen_lock_spinning has a check for the kicker interrupts
and if it is not initialized it will spin normally (not enter
the slowpath).

But for PVHVM case we would initialize the kicker interrupt
before the CPU came online. This meant that if the booting
CPU used a spinlock and went in the slowpath - it would
enter the slowpath and block forever. The forever part because
during bootup: the spinlock would be taken _before_ the CPU
sets itself to be online (more on this further), and we enter
to poll on the event channel forever.

The bootup CPU (see commit 2701b7a2166cd728fa222a434f80c2b0e6131dbf
"xen/smp: initialize IPI vectors before marking CPU online"
for details) and the CPU that started the bootup consult
the cpu_online_mask to determine whether the booting CPU should
get an IPI. The booting CPU has to set itself in this mask via:

  set_cpu_online(smp_processor_id(), true);

However, if the spinlock is taken before this (and it is) and
it polls on an event channel - it will never be woken up as
the kernel will never send an IPI to an offline CPU.

Note that the PVHVM logic in sending IPIs is using the HVM
path which has numerous checks using the cpu_online_mask
and cpu_active_mask. See above mention git commit for details.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
arch/x86/xen/enlighten.c
arch/x86/xen/smp.c