From: David Vrabel <david.vrabel@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: PCI SERR NMI may cause Xen to deadlock
Date: Tue, 31 Jan 2012 16:37:27 +0000 [thread overview]
Message-ID: <4F2818C7.1050702@citrix.com> (raw)
If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.
I don't think removing the console_force_unlock() is sufficient as it
looks like printk() is unsafe to call from NMI context. We would like
keep the diagnostic. Does the following (untested) patch to defer the
printk() to a softirq look like a valid approach?
I also considered passing the NMI to dom0 (like other NMIs are) but I
couldn't see how NMIs were handled in the current upstream pv-ops kernels.
diff -r e2722b24dc09 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/traps.c Tue Jan 31 16:28:45 2012 +0000
@@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
st->vcpu = NULL;
}
+static void pci_serr_softirq(void)
+{
+ printk("\n\nNMI - PCI system error (SERR)\n");
+}
+
void async_exception_cleanup(struct vcpu *curr)
{
int trap;
@@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int
static void pci_serr_error(struct cpu_user_regs *regs)
{
- console_force_unlock();
- printk("\n\nNMI - PCI system error (SERR)\n");
-
outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI
SERR error line. */
+
+ /* Would like to print a diagnostic here but can't call printk()
+ from NMI context -- raise a softirq instead. */
+ raise_softirq(PCI_SERR_SOFTIRQ);
}
static void io_check_error(struct cpu_user_regs *regs)
@@ -3563,6 +3569,7 @@ void __init trap_init(void)
cpu_init();
open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+ open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
}
long register_guest_nmi_callback(unsigned long address)
diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
--- a/xen/include/asm-x86/softirq.h Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/softirq.h Tue Jan 31 16:28:45 2012 +0000
@@ -6,6 +6,7 @@
#define VCPU_KICK_SOFTIRQ (NR_COMMON_SOFTIRQS + 2)
#define MACHINE_CHECK_SOFTIRQ (NR_COMMON_SOFTIRQS + 3)
-#define NR_ARCH_SOFTIRQS 4
+#define PCI_SERR_SOFTIRQ (NR_COMMON_SOFTIRQS + 4)
+#define NR_ARCH_SOFTIRQS 5
#endif /* __ASM_SOFTIRQ_H__ */
David
next reply other threads:[~2012-01-31 16:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 16:37 David Vrabel [this message]
2012-01-31 17:09 ` PCI SERR NMI may cause Xen to deadlock Keir Fraser
2012-02-01 12:03 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F2818C7.1050702@citrix.com \
--to=david.vrabel@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.