From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: Disable IOAPIC earlier during shutdown Date: Tue, 1 Dec 2015 16:38:32 +0000 Message-ID: <565DCD08.706@citrix.com> References: <1448986393-16255-1-git-send-email-ross.lagerwall@citrix.com> <565DD83D02000078000BAEE8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <565DD83D02000078000BAEE8@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ross Lagerwall Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/12/15 16:26, Jan Beulich wrote: >>>> On 01.12.15 at 17:13, 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