From: Toshi Kani Subject: Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutex deadlock (x86_cpu_hotplug_driver_mutex) Date: Wed, 08 May 2013 12:59:38 -0600 Message-ID: <1368039578.30363.71.camel@misato.fc.hp.com> References: <20130506125937.GA14036@phenom.dumpdata.com> <20130507190024.GA4303@phenom.dumpdata.com> <20130508125414.GB30955@pd.tnic> <20130508140342.GA8152@phenom.dumpdata.com> <20130508142949.GC30955@pd.tnic> <20130508163249.GB369@phenom.dumpdata.com> <1368037185.30363.58.camel@misato.fc.hp.com> <20130508184206.GD11906@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20130508184206.GD11906@phenom.dumpdata.com> Sender: linux-kernel-owner@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: Borislav Petkov , prarit@redhat.com, rafael.j.wysocki@intel.com, isimatu.yasuaki@jp.fujitsu.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, fenghua.yu@intel.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, 2013-05-08 at 14:42 -0400, Konrad Rzeszutek Wilk wrote: > On Wed, May 08, 2013 at 12:19:45PM -0600, Toshi Kani wrote: > > On Wed, 2013-05-08 at 12:32 -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, May 08, 2013 at 04:29:49PM +0200, Borislav Petkov wrote: > > > > On Wed, May 08, 2013 at 10:03:42AM -0400, Konrad Rzeszutek Wilk= wrote: > > > >=20 > > > > [ =E2=80=A6 snip some funky BIOS code ] > > > >=20 > > > > > [here it shifts and continues on testing each CPU bit] > > > > >=20 > > > > > > Questions over questions...? > > > > >=20 > > > > > I probably went overboard with my answers :-) > > > >=20 > > > > Konrad, you're killing me! :-) You actually went and looked at = the > > > > BIOS disassembly voluntarily. You must be insane, I think you s= hould > > > > immediately go to the doctor now for a thorough checkup. :-) > > > >=20 > > > > I think I know who I can sling BIOS issues now to. > > >=20 > > > Great .. :-) > > > >=20 > > > > > > Looks like save_mc_for_early would need another, local mute= x to fix that. > > > > >=20 > > > > > Let me try that. Thanks for the suggestion. > > > >=20 > > > > Ok, seriously now: yeah, this was just an idea, it should at le= ast get > > > > the nesting out of the way. > > > >=20 > > > > About the BIOS deal: you're probably staring at some BIOS out t= here > > > > but is this the way that it is actually going to be implemented= on > > > > the physical hotplug BIOS? I mean, I've only heard rumors about= IVB > > > > supporting physical hotplug but do you even have access to such= BIOS to > > > > verify? > > >=20 > > > Unfortunatly not. I am getting an IvyTown box so hopefully that h= as this > > > support. But I thought that Fenghua did since he mentioned in the= patch. > > >=20 > > > Besides that I think this can also appear on VMWare if one is doi= ng=20 > > > CPU hotplug and on some HP machines - let me CC the relevant peop= le > > > extracted from drivers/acpi/processor_driver.c. > > > (see https://lkml.org/lkml/2013/5/7/588 for the thread) > >=20 > > >From the stack trace, it looks like a bug in save_mc_for_early(). = This > > function may not call cpu_hotplug_driver_lock() during CPU online. = I > > suppose it intends to protect from CPU offline when microcode is up= dated > > outside of the boot/CPU online context. If it indeed supports upda= ting > > the microcode without using reboot/cpu hotplug, the lock should be = held > > when such update request is made. >=20 >=20 > Hey Toshi, >=20 > The fix for this I have posted, but I am more curious whether you hav= e > seen on baremetal this issue? Meaning using CPU ACPI hotplug on v3.9? Oh, I see. No, I do not have a beremetal test machine that supports CP= U hotplug yet. My initial target is to support CPU hotplug on VMs. I di= d not hit this issue since my test env was limited to CPU hot-delete followed by CPU hot-add. In such case, uci->valid is still set during CPU hot-add and does not get into this code path. I am not sure if uci->valid is supposed to be set after CPU hot-delete, though. Thanks, -Toshi