[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/5] xen/spinlock: Fix locking path engaging too soon under PVHVM.
On Mon, Sep 09, 2013 at 11:31:23AM +0100, David Vrabel wrote: > On 07/09/13 14:46, Konrad Rzeszutek Wilk wrote: > > 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 > > b/c? Ewww. Proper English please. > > > during bootup the interrupts are disabled - so the CPU would > > never get an IPI kick and would stay stuck in the slowpath > > logic forever. > > This description isn't right -- VCPUs blocked in SCHEDOP_poll can be > unblocked on the event they're waiting for even if local irq delivery is > disabled. > > > 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: > > I can't find where the online mask is being checked in > xen_send_IPI_one(). Is this really the reason why it didn't work? More details in fc78d343fa74514f6fd117b5ef4cd27e4ac30236 Author: Chuck Anderson <chuck.anderson@xxxxxxxxxx> Date: Tue Aug 6 15:12:19 2013 -0700 xen/smp: initialize IPI vectors before marking CPU online I will add that part in. > > This fix looks fine but both the description and the comment need to be > fixed/clarified. U r Right! > > David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |