Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutexdeadlock (x86_cpu_hotplug_driver_mutex)

From: Borislav Petkov
Date: Wed May 08 2013 - 08:54:00 EST


On Tue, May 07, 2013 at 03:00:24PM -0400, Konrad Rzeszutek Wilk wrote:
> I dug deeper in how QEMU does it and it looks to be actually doing
> the right thing. It triggers the ACPI SCI, the method that figures
> out the CPU online/offline bits kicks off the right OSPM notification
> and everything is going through ACPI (so _STA is on the processor is
> checked, returns 0x2 (ACPI_STA_DEVICE_PRESENT), MADT has now the CPU
> marked as enabled).

AFAIUC, you mean physical hotplug here which is done with ACPI, right?
And, if so, we actually need an x86 machine which supports that to test
it on. Also, is this how physical hotplug is done? Put the number of
max. supported CPUs in MADT and those which are not present are marked
as disabled?

Then, when they're physically hotplugged, ACPI marks them as enabled?
Questions over questions...?

> I am now 99% sure you would be able to reproduce this on baremetal with
> ACPI hotplug where the CPUs at bootup are marked as disabled in MADT.
> (lapic->lapic_flags == 0).
>
> The comment for calling save_mc_for_early says:

Looks like save_mc_for_early would need another, local mutex to fix that.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/