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

Re: [Xen-devel] [PATCH] x86: Disable IOAPIC earlier during shutdown

>>> On 01.12.15 at 17:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 01/12/15 16:26, Jan Beulich wrote:
>>>>> On 01.12.15 at 17:13, <ross.lagerwall@xxxxxxxxxx> wrote:
>>> Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
>>> (take 2)") introduced a regression on some hardware where Xen would hang
>>> during shutdown, repeating the following message:
>>> APIC error on CPU0: 08(08), Receive accept error
>>> This appears to be because an interrupt (in this case from the serial
>>> console) destined for a CPU other than the boot CPU is left unhandled so
>>> an APIC error on CPU 0 is generated instead.
>>> To fix this, disable the IOAPIC before each CPU's local APIC is
>>> disabled so that these interrupts are not generated.
>> But wouldn't a similar issue occur for MSI or MSI-like (IOMMU)
>> interrupts? I.e. shouldn't we perhaps invoke fixup_irqs() after
>> having restricted cpu_online_map to just CPU0?
> a fixup_irq()s in __stop_this_cpu() might do it, although there will be
> heavy lock contention on all the irq descriptors.
> A better option would be to run fixup_irq()s once and make them all
> point to cpu0, then take the others down.  This will probably involve
> passing a parameter to fixup_irq()s to conditionally override its use of
> the cpu_online_map.

The latter was what I actually had in mind, I just didn't check
whether we can re-write cpu_online_map up front (which it looks
like we can't). So yes, passing fixup_irqs() a cpumask would be
the way to go.


Xen-devel mailing list



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