search for: rmrr

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 experiment, I delete the "return -EFAULT" and re-compiling Xe...

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 experiment, I delete the "return -EFAULT" and re-compiling Xe...

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

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

...#39;'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: 0000000000000000 - 000000000009e400 (usable) 000000000009e400 - 00000000000a0000 (reserved) 00000000000e4c00 - 0000000000100000 (reserved) 0000000000100000 - 00000000bf780000 (usable)...

...s of combinations of Xen versions and kernels to get this working. And, yes, VT and VT-d are enabled in my BIOS. 1) CentOS 5.2 SRPMS compiled with Xen 3.2.1. Adding pci=nommconf does not get it to boot. 2) Mercurial Xen-3.2-testing. Here, after adding pci=nommconf, I get: (XEN) [VT-D]dmar.c:441: RMRR is incorrect. (XEN) Failed to parse ACPI DMAR. Disabling VT-d. (XEN) [VT-D]ACPI DMAR:No DMAR devices found 3) Mercurial Xen-unstable, I get "I/O Virtualisation disabled" I can''t find any reason why this is the case. VT-D is not enabled. I would really like to find the cause fo...

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 module /vmlinuz-2.6.18.8-xen ro root=/dev/XenVolGroup/LogVolXenDom0 rhgb quiet pciback.hide=(01:0...

Further to my messages back in May I have at last got round to trying to get my DomU to recognise USB devices. I am using Xen 4.6 with CentOS kernel 3.18.34-20.el7.x86_64. I have to manually make the port available before creating the DomU by issuing the command: xl pci-assignable-add 00:1a.0 otherwise nothing shows in: xl pci-assignable-list I have added this to my .cfg file as per the

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

...gth; ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - dmaru, DMAR_TYPE, drhd->segment); + &dmaru->scope, DMAR_TYPE, drhd->segment); if ( dmaru->include_all ) { @@ -590,7 +588,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_hea dev_scope_start = (void *)(rmrr + 1); dev_scope_end = ((void *)rmrr) + header->length; ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - rmrru, RMRR_TYPE, rmrr->segment); + &rmrru-...

...this board, I have tried many workarounds > and it always results in failure. > > > Hello, did you get a reply? Somebody else has something new about the Asus P6T and this problem? How about VT-d on windows systems? Thanks! -- View this message in context: http://www.nabble.com/VT-D-RMRR-is-incorrect-tp22005500p24661872.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

During parsing DMAR table, if find RMRR is incorrect, return error. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...> see my post on ASUS forum: http://vip.asus.com/forum/view.aspx?id=20090402224408018&SLanguage=en-us&board_id=1&model=P6T%20Deluxe&page=1 Please BUMP if you view ;) Dustin, you still thinking of contacting ASUS ? -- View this message in context: http://www.nabble.com/VT-D-RMRR-is-incorrect-tp22005500p22855886.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

This adds a boolean boot parameter to xen to allow reserved memory regions to be added to the iommu mappings for dom0. The parameter is "iommu_include_reserved" and is off by default. A warning is also traced when incorrect RMRR to system memory map values are detected. This is being added to address some incorrect BIOS''s that do not report correctly the requied reserved memory ranges in the RMRRs. When this occurs it currently can cause early boot hangs and crashes. Signed-off-by: Ross Philipson <ross.philips...

...or -110 [ 45.392067] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 55.824112] usb 1-1: device not accepting address 5, error -110 I am looking at xl dmesg in Dom0 where there are some messages relating to the PCI usb: [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom6. (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom6 failed (-1) (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom7. (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom8. (XEN) [VT-D] It's...

...file, lspci in dom0, and lspci in your domU to xen-users? There will be a lot more eyeballs there to help you get things sorted out. > I am looking at xl dmesg in Dom0 where there are some messages relating to > the PCI usb: > [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at 7b800000 > for Dom6. > (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom6 failed (-1) > (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 > for Dom7. > (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 > for D...

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 ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:413:   dmaru-...

...emoves the need to carve the window out of the whole guest. > Another thing I want to ask your opinion, about whether there is value of > adding another subtype (MEM_T_IDENTITY), asking for identity mapping > in the address space. It's similar to Reserved Memory Region Reporting > (RMRR) structure defined in VT-d, to indicate BIOS allocated reserved > memory ranges which may be DMA target and has to be identity mapped > when DMA remapping is enabled. I'm not sure whether ARM has similar > capability and whether there might be a general usage beyond VT-d. For > now...

...emoves the need to carve the window out of the whole guest. > Another thing I want to ask your opinion, about whether there is value of > adding another subtype (MEM_T_IDENTITY), asking for identity mapping > in the address space. It's similar to Reserved Memory Region Reporting > (RMRR) structure defined in VT-d, to indicate BIOS allocated reserved > memory ranges which may be DMA target and has to be identity mapped > when DMA remapping is enabled. I'm not sure whether ARM has similar > capability and whether there might be a general usage beyond VT-d. For > now...

...stand and thanks for elaboration. > > > Another thing I want to ask your opinion, about whether there is value of > > adding another subtype (MEM_T_IDENTITY), asking for identity mapping > > in the address space. It's similar to Reserved Memory Region Reporting > > (RMRR) structure defined in VT-d, to indicate BIOS allocated reserved > > memory ranges which may be DMA target and has to be identity mapped > > when DMA remapping is enabled. I'm not sure whether ARM has similar > > capability and whether there might be a general usage beyond VT-d...