From: Suresh Siddha <suresh.b.siddha@intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Chris Wright <chrisw@sous-sol.org>,
Max Asbock <masbock@linux.vnet.ibm.com>,
"indou.takao@jp.fujitsu.com" <indou.takao@jp.fujitsu.com>,
Bjorn Helgaas <bjorn.helgaas@hp.com>,
David Woodhouse <dwmw2@infradead.org>,
"stable@kernel.org" <stable@kernel.org>
Subject: Re: [patch 1/4] vt-d: quirk for masking vtd spec errors to platform error handling logic
Date: Mon, 06 Dec 2010 12:26:30 -0800 [thread overview]
Message-ID: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> (raw)
In-Reply-To: <20101206092749.7f89f3fd@jbarnes-desktop>
On Mon, 2010-12-06 at 09:27 -0800, Jesse Barnes wrote:
> Can we make these registers and bits a bit more self-documenting (i.e.
> #defines for both, maybe along with other useful bit definitions for
> this reg)? Also, "error" is misspelled as "erorr" above. :)
Thanks for the review. Appended the updated patch. I haven't used
#defines for the pci-id's, as the first one (IOH) is used by several
chipsets and the second one is not named yet.
---
From: Suresh Siddha <suresh.b.siddha@intel.com>
Subject: vt-d: quirk for masking vtd spec errors to platform error handling logic
On platforms with Intel 7500 chipset, there were some reports of system
hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled.
During kdump, there is a window where the devices might be still using old
kernel's interrupt information, while the kdump kernel is coming up. This can
cause vt-d faults as the interrupt configuration from the old kernel map to
null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled,
we still have the same issue but in this case we will see benign spurious
interrupt hit the new kernel).
Based on platform config settings, these platforms seem to generate NMI/SMI
when a vt-d fault happens and there were reports that the resulting SMI causes
the system to hang.
Fix it by masking vt-d spec defined errors to platform error reporting logic.
VT-d spec related errors are already handled by the VT-d OS code, so need to
report the same error through other channels.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: stable@kernel.org [v2.6.32+]
---
drivers/pci/quirks.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
Index: tip/drivers/pci/quirks.c
===================================================================
--- tip.orig/drivers/pci/quirks.c
+++ tip/drivers/pci/quirks.c
@@ -2764,6 +2764,29 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RI
DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
#endif /*CONFIG_MMC_RICOH_MMC*/
+#if defined(CONFIG_DMAR) || defined(CONFIG_INTR_REMAP)
+#define VTUNCERRMSK_REG 0x1ac
+#define VTD_MSK_SPEC_ERRORS (1 << 31)
+/*
+ * This is a quirk for masking vt-d spec defined errors to platform error
+ * handling logic. With out this, platforms using Intel 7500, 5500 chipsets
+ * (and the derivative chipsets like X58 etc) seem to generate NMI/SMI (based
+ * on the RAS config settings of the platform) when a vt-d fault happens.
+ * The resulting SMI caused the system to hang.
+ *
+ * VT-d spec related errors are already handled by the VT-d OS code, so no
+ * need to report the same error through other channels.
+ */
+static void vtd_mask_spec_errors(struct pci_dev *dev)
+{
+ u32 word;
+
+ pci_read_config_dword(dev, VTUNCERRMSK_REG, &word);
+ pci_write_config_dword(dev, VTUNCERRMSK_REG, word | VTD_MSK_SPEC_ERRORS);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, vtd_mask_spec_errors);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3c28, vtd_mask_spec_errors);
+#endif
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
next prev parent reply other threads:[~2010-12-06 20:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 6:22 [patch 0/4] x86, intr-remapping patches for addressing kexec/kdump issues Suresh Siddha
2010-12-01 6:22 ` [patch 1/4] vt-d: quirk for masking vtd spec errors to platform error handling logic Suresh Siddha
2010-12-01 7:26 ` Chris Wright
2010-12-06 17:27 ` Jesse Barnes
2010-12-06 20:26 ` Suresh Siddha [this message]
2010-12-06 20:44 ` Jesse Barnes
2010-12-06 21:02 ` Suresh Siddha
2010-12-06 23:01 ` Max Asbock
2010-12-14 1:15 ` [tip:x86/urgent] x86, vt-d: Quirk " tip-bot for Suresh Siddha
2010-12-01 6:22 ` [patch 2/4] x86, vtd: fix the vt-d fault handling irq migration in the x2apic mode Suresh Siddha
2010-12-01 8:52 ` Chris Wright
2010-12-01 15:14 ` Bjorn Helgaas
2010-12-01 17:40 ` Suresh Siddha
2010-12-07 17:38 ` Takao Indoh
2010-12-14 1:16 ` [tip:x86/urgent] x86, vt-d: Fix " tip-bot for Kenji Kaneshige
2010-12-01 6:22 ` [patch 3/4] x86: enable the intr-remap fault handling after local apic setup Suresh Siddha
2010-12-01 8:51 ` Chris Wright
2010-12-14 1:16 ` [tip:x86/urgent] x86: Enable the intr-remap fault handling after local APIC setup tip-bot for Kenji Kaneshige
2010-12-01 6:22 ` [patch 4/4] vt-d: handle previous faults after enabling fault handling Suresh Siddha
2010-12-01 8:52 ` Chris Wright
2010-12-14 1:17 ` [tip:x86/urgent] x86, vt-d: Handle " tip-bot for Suresh Siddha
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=1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=bjorn.helgaas@hp.com \
--cc=chrisw@sous-sol.org \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masbock@linux.vnet.ibm.com \
--cc=mingo@redhat.com \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®