similar to: [PATCH] [VTD] Add RMRR check in DMAR parsing

Fix addr_to_dma_page() issue to return l1e correctly, and also clean up rmrr mapping code, make sure setup rmrr identify mapping just once per domain. This patch fixes the VT-d bug (Fail to boot smp Linux guest with VT-d NIC assigned on IA32e platform). Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list

Purchased DQ35JO on Vt-d/PCI passthrough wiki''s recommendations. Built latest xen-unstable and am getting the following via ''xm dmesg'': (XEN) [VT-D]dmar.c:374: RMRR error: base_addr d0000000 end_address cfffffff (XEN) Failed to parse ACPI DMAR. Disabling VT-d. My grub.conf looks like this: kernel /xen.gz vga=mode-0x0317 vtd=1 iommu=1

This patch removes a wrong if condition judgement to setup rmrr identify mapping for guests, and passes page count rather than address size to iommu_flush_iotlb_psi(). Signed-off-by: Weidong Han <weidong.han@intel.com> Signed-off-by: Anthony Xu <Anthony.xu@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

For IOAPIC interrupt remapping, it only needs to remap ioapci RTE, should not remap other IOAPIC registers, which are IOAPIC ID, VERSION and Arbitration ID. This patch adds the check for this and only remap ioapci RTE. Signed-off-by: Anthony Xu <anthony.xu@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing

The patches are as follows: Patch 1: Map RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Patch 2: There is only one INCLUDE_ALL DMAR unit in system, but no restriction on whether it''s the last unit. Patch 3: Change code style of pci.c file, and add spin_unlock(&pdev->lock) when

Rather than requiring the scopes to be the first members of their respective structures (so that casts can be used to switch between the different views), properly use types and container_of(). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -304,13 +304,15 @@ static int __init scope_device_count(con

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 ....#...........

Hi, I''m not able to activate VT-d on my PC due to a buggy BIOS. Xen fails to parse ACPI DMAR table. There is a problem with RMRR address range. My configuration is : - Debian Weezy - Xen version 4.1.2 (Debian 4.1.2-2) - Sabertooth X58 with last bios (1304) - i7 - 960 I have the following message : (XEN) [VT-D]dmar.c:704: Host address width 39 (XEN) [VT-D]dmar.c:719: found

I''m using (XEN) Xen version 4.1.2 (Debian 4.1.2-2) (waldi at debian dot org) (gcc version 4.6.2 (Debian 4.6.2-6) ) Sat Dec 10 19:58:21 UTC 2011 With VT-d enabled in BIOS the ACPI Direct Memory Access remapping (DMAR) in the P6T Deluxe V2 (BIOS 1202, 2011/10/10) reports RMRR (Reserved Memory Region Reporting Structure) is bf7dc000 - bf7dbfff e820 table:

If pass-through field in extended capability register is set, set pass-through translation type for Dom0, that means DMA requests with Untranslated addresses are processed as pass-through in Dom0, needn''t translate DMA requests through a multi-level page-table. Signed-off-by: Anthony Xu <anthony.xu@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com>

This patch maps RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Currently, hypervisor sets up devices and RMRR for dom0, and dom0 also adds devices for itself via hypercall. This is obviously duplicate. In order to allow old dom0 kernels to work with iommu-capable platforms, maybe it cannot be

Hello, I''m also seeing this exact same problem. I''ve posted on xen-users, but did not get an answer. Venkat seems to be experiencing the same problem as me. I have the latest BIOS for my motherboard DQ35JO. (BIOS ver 933) I''m running a Q6600 as well. It hangs at "Brought up 4 CPUs." I''ve tried all sorts of combinations of Xen versions and kernels to

Setting isa irq mapping in hvm_do_IRQ_dpci() costs time when each interrupt occurs, and it doesn''t update isa irq mapping when pci_link is updated. This patch fixes this issue. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

MSI-x may have multiple vectors, however in current interrupt remapping code, one device only has one entry in interrupt remapping table. This patch adds ''remap_index'' in msi_desc structure to track its index in interrupt remapping table. Signed-off-by: Haitao Shan <haitao.shan@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com>

When ir_ctrl->iremap_index == -1, it means there is no remap entry. So it needn''t to convert from remap format to normal ioapic format. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch cleans up iommu code. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

Hi list, I have a problem with a new laptop (reproducable on other machines too) and the xen hypervisor. When the hypervisor gets booted with VESA mode 800x600 I see some messages and then the screen contents is switched into a pattern of vertical colored lines and never comes back. In text mode all works well, but later the pattern appears when the X servers starts. I disabled VTd in the bios

lspci -vvv and -t attached Serial console output: http://pastebin.ca/2177395 Main error appears to be: (XEN) [VT-D]iommu.c:858: iommu_fault_status: Primary Pending Fault (XEN) [VT-D]iommu.c:833: DMAR:[DMA Read] Request device [00:1e.0] fault addr df8e5000, iommu reg = ffff82c3fff57000 (XEN) DMAR:[fault reason 06h] PTE Read access is not set onboard nic on the same bus is going