similar to: [PATCH 0/5] VT-d support for PV guests

On map: only flush when old PTE was valid or invalid PTE may be cached. On unmap: always flush old entry, but skip flush for unaffected IOMMUs. Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com> -- iommu.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- diff -r 8187fd8113f9 xen/drivers/passthrough/vtd/iommu.c ---

The memory relating guest domain should be allocated from NUMA node on which the guest runs. Because the latency of the same NUMA node is faster than that of a different one. This patch fixes memory allocation for Address Translation Structure of VT-d. VT-d uses two types of Structures for DMA address translation. The one is Device Assignment Structure. The other is Address Translation

On Xen-3.3.0, domain0 Megaraid SAS (SAS 1068 controller) driver is not loading correctly if vtd support in Xen is enabled. It fails at the point of initializing firmware. I wasn''t seeing this error with Xen-3.2.2-rc3 (Unstable version), though with vtd disabled in Xen-3.3.0, it is working. Looks like a degrade problem. Any clues? Thx, Venkat

hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#...........

Fixes made in version 2: 1) Use PML4[257] for ioremap of PCI mmcfg. As full 16-bit segment support would require 44-bits. Since each slot only has 39-bits, we support 2048 PCI segments for now. This can be easily expanded if deemed necessary in the future. 2) Integrated PCI mmcfg access with existing PCI config interface for x86_64. Use MMCFG interface if offset is greater than 256.

Hi Tim, Could you please have a look at this bug? Thanks a lot. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774 Best Regards, Yongjie Ren (Jay) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Keir, This patch will move reading and writing of PCI configuration spaces from dom0 to Xen. It also changes VTD code, so that they can touch the PCI configuration spaces with proper lock. This will also benefit MSI support in Xen. Can you give some comments? Thanks! <<pci_conf_xen.patch>> Best Regards Haitao Shan _______________________________________________ Xen-devel

diff -r e6266fc76d08 -r 6feac926cf80 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Fri Jul 27 12:22:13 2012 +0200 +++ b/xen/drivers/passthrough/vtd/iommu.c Mon Jul 30 15:35:16 2012 -0700 @@ -2137,6 +2137,15 @@ int __init intel_vtd_setup(void) { iommu = drhd->iommu; + printk("Intel VT-d supported page sizes: 4kB"); + if

Hi, Keir, These patches are rebased version of Yunhong''s original patches, which were sent out before XEN 3.2 was released. These patches enable MSI support and limited MSI-X support in XEN. Here is the original description of the patches from Yunhong''s mail. The basic idea including: 1) Keep vector global resource owned by xen, while split pirq into per-domain

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, We met several system failures on different hardware platforms, which are all caused by VT-d fault. err 1: disk is corrupted by VT-d fault on SATA. err 2: Dom0 kernel panics at booting, which is caused VT-d fault on UHCI. err 3, Dom0 complains disk errors while creating HVM guests. The culprit would be changeset 19054 "x86_64: Remove statically-partitioned Xen heap.". Detailed

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

http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html Stepping B-3 has two errata (#47 and #53) related to Interrupt remapping, to which the workaround is for the BIOS to completely disable interrupt remapping. These errata are fixed in stepping C-2. Unfortunately this chipset is very common and many BIOSes are not disabling remapping. We can

Hello, I''m having problems with VTD on this board. The board/cpu/bios all support vt-d and I think maybe I''m just missing something? Any feedback would be much appreciated :) Output below: root@vm:~# xm create /etc/xen/vm-nine.cfg Using config file "/etc/xen/vm-nine.cfg". Error: Failed to assign device to IOMMU (0000:05:00.0@100,msitranslate=1,power_mgmt=0)

Hello, I''m having problems with VTD on this board. The board/cpu/bios all support vt-d and I think maybe I''m just missing something? Any feedback would be much appreciated :) Output below: root@vm:~# xm create /etc/xen/vm-nine.cfg Using config file "/etc/xen/vm-nine.cfg". Error: Failed to assign device to IOMMU (0000:05:00.0@100,msitranslate=1,power_mgmt=0)

Hey everyone, I realize that people asking about PCI passthrough has been thoroughly beaten to death many a time, however I couldn''t find the answer to these questions anywhere (and I''d really like to know :P) so please just bare with me. I know the GART built into AMD chipsets can act as a "mini IOMMU" and do DMA translation but not protection/isolation. However,

I try pci pci passthrough with xen 3.3.1 and CentOS 5.2(64bit) on a SUPERMICRO C7X58 board I see the following the error in my boot log. (XEN) [VT-D]dmar.c:372: RMRR is incorrect. This problem is caused by this condition in dmr.c:372. if ( rmrr->base_address >= rmrr->end_address ) { dprintk(XENLOG_ERR VTDPREFIX, "RMRR is incorrect.\n"); return -EFAULT; } As an

I try pci pci passthrough with xen 3.3.1 and CentOS 5.2(64bit) on a SUPERMICRO C7X58 board I see the following the error in my boot log. (XEN) [VT-D]dmar.c:372: RMRR is incorrect. This problem is caused by this condition in dmr.c:372. if ( rmrr->base_address >= rmrr->end_address ) { dprintk(XENLOG_ERR VTDPREFIX, "RMRR is incorrect.\n"); return -EFAULT; } As an

Xen 3.4 xen-unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create

Hello XCI developers, I have a HP6930, downloaded xenclient from the git. And by following the instruction in HOWTO, I could get xenclient boot up fine. I try then to start a guest using xenvm.readme as template and nothing shows on the screen for the guest, although xenops shows 2 doms running. Can you point me to how to start a guest. And also, is the tree downloaded from git enough to arrive