similar to: [PATCH] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

All, just having spotted the backport of Linux commit 03bbcb2e I notice a certain discrepancy with the Xen commit having the same purpose as well as with the actual specification updates: The Linux solution keys off of device IDs 3403 and 3406, as listed in the specification update, but this way fails to cover the X58 chipset, which has - under different numbers (62 and 69) - the same errata

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called as introduced with the patch "x86-64: detect processors subject to AMD erratum #121 and

The time has come for another round of stable releases. Please send (or resend) any outstanding backport requests for 4.0.4 and 4.1.3 before Friday 20 April. Note that 4.0.4 will likely be the last release in the 4.0.x branch. Ian.

Wei, Quick question: Am I reading the code correctly, that even with per-device interrupt remap tables, that GSIs are accounted to the intremap table of the corresponding IOAPIC, presumably because the IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In that case, then we need all devices sharing the same IOAPIC must not have any vector collisions. Is that correct? -George

On 7/28/2016 3:41 PM, Fawzy Ibrahim wrote: > LSI SATA MEGARAID 95Q9 afaik, the megaraid cards are mostly all SAS, which support SATA drives, except very old ones were SCSI. Ok, I do see they had a series of MegaRAID SATA 150-xx and 300-xx cards, these were 64 bit PCI or PCI-X cards. 95Q9 does not appear to be a valid card number, 9240, 9260, 9280 are some pci-express SAS MegaRaid

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

Greetings, I'm trying to add a virtual nic to an existing and active vm and I'm getting this error: error: internal error: No more available PCI slots the cmd I'm trying to run is: virsh -c qemu:///system attach-interface --domain router --type bridge --source virbr0 --model virtio --config --live the lspci output within the vm is this: # lspci 00:00.0 Host bridge: Intel Corporation

John R Pierce wrote: > On 7/26/2016 10:20 AM, Fawzy Ibrhim wrote: >> I want to install Centos 7 latest build on NEC Server 5800/120b-2. >> >> The installation wizard fails to detect the storage connected to LSI >> SATA MegaRaid PCI. > > which megaraid card? they've made quite a lot. lspci will list the > card type... > > linux will only see storage

During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn''t passed back correctly. While this is benign in most cases (as the value isn''t being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan

Hello, I''m hoping someone may be able to push us in the right direction. I''m trying to get one of our products to work with the current branch of Xen (4.0/4.0.0) but I''m hitting a problem. We are currently using Xen 3.3.2 on a Sun Blade 600 chassis (with x6270 blades) this works great. But when we upgrade to Xen 4.0/4.0.1 we get the following message when

Greetings, I''m attempting to do gfx_passthru with the primary graphics adapter (03:00.0), passing it to a guest. I can unbind it from the host but when I fire up the guest OS my monitor loses signal from the graphics card and that''s that. The GFX card is dual DVI, I''ve tried both slots. Host is Linux 2.6.32.14-1.2.105.xendom0.fc12.x86_64, Guest is Windows 7. PC is an

Hi, I''ve been trying to boot stefano''s minimal dom0 kernel from git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 2.6.36-rc1-initial-domain-v2+pat On xen-unstable, I get the following WARN_ON()''s from Xen when bringing up the NIC''s, then the machine hangs forever when trying to login either over serial or NIC. (XEN) Xen WARN at msi.c:649 (XEN) ----[

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

Dear mailinglist, I own a Gigabyte motherboard GA 970A UD3 with IOMMU support. Since the update XSA-36 (also part of the latest debian wheezy pkg), the IO-Virtualisation does not work any more as discussed on this mailinglist [0] and [1]. I like to ask, if there is an "official" solution in sight. I''m not sure about my alternatives. How "dangerous" is the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-0153 / XSA-36 version 3 interrupt remap entries shared and old ones not cleared on AMD IOMMUs UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= To avoid an erratum in early hardware, the Xen AMD IOMMU code by default chooses to use a single interrupt

Is there a way to enable iommu I have hp 380 g6 and I get this (XEN) [VT-D]Disabling IOMMU due to Intel 5500/5520/X58 Chipset errata #47, #53 (XEN) I/O virtualisation disabled _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

So I want to turn iommu support on in a guest ( <type arch='x86_64' machine='pc-q35-4.1'>hvm</type>). Per [1] I tried to add to devices either <devices> <iommu model='intel'> <driver intremap='on'/> </iommu> </devices> or just a simpler <devices> <iommu model='intel /'> </devices>

Hi all. Like many of us, I''m currently struggling with Rails deployment. Like maybe only a few of us, I''m responsible not for one or two webapps but dozens. Currently, we deploy them as war files using JBoss'' hot deployment feature, which amounts to copying a war file to a directory monitored by JBoss. Undeploying the app amounts to removing it from the directory.

XSA-36 changed the default vector map mode from global to per-device. This is because a global vector map does not prevent one PCI device from impersonating another and launching a DoS on the system. However, the per-device vector map logic is broken for devices with multiple MSI-X vectors, which can either result in a failed ASSERT() or misprogramming of a guests interrupt remapping tables.