On 01/12/15 16:26, Jan Beulich wrote:
>>>> On 01.12.15 at 17:13, <ross.lagerw...@citrix.com> 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
