[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata

On 17/01/13 08:49, Jan Beulich wrote:
On 16.01.13 at 22:09, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
On 16/01/13 13:57, Jan Beulich wrote:
On 16.01.13 at 00:27, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
+/* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
+ * Fixed in stepping C-2. */
+void __init tylersburg_intremap_quirk(void)
+    uint32_t bus, device;
+    uint8_t rev;
+    for ( bus = 0; bus < 0x100; bus++ )
+    {
+        /* Match on System Management Registers on Device 20 Function 0 */
+        device = pci_conf_read32(0, bus, 20, 0, PCI_VENDOR_ID);
+        rev = pci_conf_read8(0, bus, 20, 0, PCI_REVISION_ID);
+        if ( rev == 0x13 && device == 0x342e8086 )
+        {
+            dprintk(XENLOG_INFO VTDPREFIX,
+                    "Disabling Interrupt Remapping due to Intel 5500/5520/X58 
Chipset errata #47, #53\n");
+            iommu_intremap = 0;
Unless it is guaranteed that no system with this chipset can have
x2APIC, I don't think this is right. For one, this happens way too
late (namely after x2apic_bsp_setup()). And second, if you move
this earlier, such systems with x2APIC pre-enabled won't boot
After some digging, I discovered that the errata affects chipsets
(5520,5500,X58) which don't have IOMMU EIM( Extended Interrupt Mode)
support. EIM is required to support x2APIC mode and so this means the
chipset can't support x2APIC mode and so we should never see a system
with x2APIC enabled.

I still don't feel well with this making a small security hole bigger
(the erratum to me mainly means that with lost interrupts we
might observe systems hangs in the worst case, or maybe
data corruption if recovery code in the OSes doesn't work well).
Whereas with interrupt remapping disabled passthrough
becomes inherently insecure (and the host vulnerable to guest

So the question really is whether, rather than disabling interrupt
remapping, disabling the IOMMU as a whole wouldn't be the
better (read: more secure) workaround.
The patch is just achieving the same effect in Xen as the BIOS workaround recommended in the Intel errata document.

I also don't like the making the security hole bigger but I think we are making an Xen IOMMU support policy change if we disable the IOMMU support when interrupt remapping is not supported.

Additionally, I believe that if we make this policy change then we will disable Xen IOMMU support for the Intel 3100/3200 chipset series.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.