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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel