[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |