[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH 1/5] 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 initialised it will spin normally (not enter
the slowpath).

But for PVHVM case we would initialise 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 b/c
during bootup the interrupts are disabled - so the CPU would
never get an IPI kick and would stay stuck in the slowpath
logic forever.

Why would the booting CPU never get an IPI kick? B/c in both
PV and PVHVM we consult the cpu_online_mask to determine whether
the IPI should go to its CPU destination. Since the booting
CPU has not yet finished and set that flag, it meant that
if any spinlocks were taken before the booting CPU had gotten to:

  set_cpu_online(smp_processor_id(), true);

it (booting CPU) we would never get the unkicker IPI
(from xen_unlock_kick) and block forever.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
---
 arch/x86/xen/enlighten.c |    1 -
 arch/x86/xen/smp.c       |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 193097e..fbc002c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1689,7 +1689,6 @@ static int xen_hvm_cpu_notify(struct notifier_block 
*self, unsigned long action,
        case CPU_UP_PREPARE:
                xen_vcpu_setup(cpu);
                if (xen_have_vector_callback) {
-                       xen_init_lock_cpu(cpu);
                        if (xen_feature(XENFEAT_hvm_safe_pvclock))
                                xen_setup_timer(cpu);
                }
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 597655b..4db779d 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -703,6 +703,15 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct 
task_struct *tidle)
        WARN_ON(rc);
        if (!rc)
                rc =  native_cpu_up(cpu, tidle);
+
+       /*
+        * We must initialize the slowpath CPU kicker _after_ the native
+        * path has executed. If we initialized it before none of the
+        * unlocker IPI kicks would reach the booting CPU as the booting
+        * CPU had not set itself 'online' in cpu_online_mask. That mask
+        * is checked when IPIs are sent (on HVM at least).
+        */
+       xen_init_lock_cpu(cpu);
        return rc;
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.