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 Xen,
I can pass a PCI device through to Gest-OS(Windows XP) and have no problem
with using the devices on Gest-OS.
Is the above condition really correct and important ?
xm dmesg results with deleting "return -EFAULT" are following.
[root@localhost ~]# xm dmesg
__ __ _____ _____ _
\ \/ /___ _ __ |___ / |___ / / |
\ // _ \ ''_ \ |_ \ |_ \ | |
/ \ __/ | | | ___) | ___) || |
/_/\_\___|_| |_| |____(_)____(_)_|
(XEN) Xen version 3.3.1 (root@(none)) (gcc version 4.1.2 20071124 (Red Hat
4.1.2-42)) Sat Feb 14 05:21:09 JST 2009
(XEN) Latest ChangeSet: unavailable
(XEN) Command line: iommu msi=1
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 0000000000099400 (usable)
(XEN) 0000000000099400 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bf790000 (usable)
(XEN) 00000000bf790000 - 00000000bf79e000 (ACPI data)
(XEN) 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS)
(XEN) 00000000bf7d0000 - 00000000bf7e0000 (reserved)
(XEN) 00000000bf7ec000 - 00000000c0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffc00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 00000001c0000000 (usable)
(XEN) System RAM: 6135MB (6282404kB)
(XEN) ACPI: RSDP 000F9C50, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF790100, 0054 (r1 112608 XSDT1738 20081126 MSFT 97)
(XEN) ACPI: FACP BF790290, 00F4 (r4 112608 FACP1738 20081126 MSFT 97)
(XEN) ACPI: DSDT BF790470, 5AA5 (r2 1F380 1F380000 0 INTL 20051117)
(XEN) ACPI: FACS BF79E000, 0040
(XEN) ACPI: APIC BF790390, 0092 (r2 112608 APIC1738 20081126 MSFT 97)
(XEN) ACPI: MCFG BF790430, 003C (r1 112608 OEMMCFG 20081126 MSFT 97)
(XEN) ACPI: OEMB BF79E040, 0072 (r1 112608 OEMB1738 20081126 MSFT 97)
(XEN) ACPI: DMAR BF79E0C0, 0118 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT BF7A0260, 1298 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) Xen heap: 14MB (14536kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC version 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #6 7:10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Processor #3 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC version 21
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) [VT-D]dmar.c:372: RMRR is incorrect.
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2660.058 MHz processor.
(XEN) VMX: EPT is available.
(XEN) VMX: VPID is available.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) CPU0: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 1/2 eip 8c000
(XEN) CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 2/4 eip 8c000
(XEN) CPU2: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 3/6 eip 8c000
(XEN) CPU3: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 4/1 eip 8c000
(XEN) CPU4: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 5/3 eip 8c000
(XEN) CPU5: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 6/5 eip 8c000
(XEN) CPU6: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Booting processor 7/7 eip 8c000
(XEN) CPU7: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
(XEN) Total of 8 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) checking TSC synchronization across 8 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 8 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 ->
0xffffffff805c190c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 00000001b6000000->00000001b8000000 (1498227 pages to
be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff805c190c
(XEN) Init. ramdisk: ffffffff805c2000->ffffffff80b88200
(XEN) Phys-Mach map: ffffffff80b89000->ffffffff81707398
(XEN) Start info: ffffffff81708000->ffffffff817084a4
(XEN) Page tables: ffffffff81709000->ffffffff81718000
(XEN) Boot stack: ffffffff81718000->ffffffff81719000
(XEN) TOTAL: ffffffff80000000->ffffffff81800000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 8 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to
Xen)
(XEN) Freed 104kB init memory.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Hello Yoshiharu-san!
Have you tried 3.4-unstable yet?
I had the same problem with my Asus P6T Deluxe board (also X58) and got
a little further on 3.4 but finally (after some more RMRR and DMAR
details displayed) the same error message.
It would be interesting to know if just the BIOSes (their DMAR maps to
be more specific) on non-Intel manufactured X58 boards are broken or if
there are general problems with X58 and Xen... has anyone gotten
VTD/IOMMU to work on X58 yet?
Best regards,
Christian
Yoshiharu Mori schrieb:>
> 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
Xen,
> I can pass a PCI device through to Gest-OS(Windows XP) and have no problem
> with using the devices on Gest-OS.
>
> Is the above condition really correct and important ?
>
> xm dmesg results with deleting "return -EFAULT" are following.
>
> [root@localhost ~]# xm dmesg
> __ __ _____ _____ _
> \ \/ /___ _ __ |___ / |___ / / |
> \ // _ \ ''_ \ |_ \ |_ \ | |
> / \ __/ | | | ___) | ___) || |
> /_/\_\___|_| |_| |____(_)____(_)_|
>
> (XEN) Xen version 3.3.1 (root@(none)) (gcc version 4.1.2 20071124 (Red
> Hat 4.1.2-42)) Sat Feb 14 05:21:09 JST 2009
> (XEN) Latest ChangeSet: unavailable
> (XEN) Command line: iommu msi=1
> (XEN) Video information:
> (XEN) VGA is text mode 80x25, font 8x16
> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN) Found 0 MBR signatures
> (XEN) Found 2 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN) 0000000000000000 - 0000000000099400 (usable)
> (XEN) 0000000000099400 - 00000000000a0000 (reserved)
> (XEN) 00000000000e0000 - 0000000000100000 (reserved)
> (XEN) 0000000000100000 - 00000000bf790000 (usable)
> (XEN) 00000000bf790000 - 00000000bf79e000 (ACPI data)
> (XEN) 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS)
> (XEN) 00000000bf7d0000 - 00000000bf7e0000 (reserved)
> (XEN) 00000000bf7ec000 - 00000000c0000000 (reserved)
> (XEN) 00000000fee00000 - 00000000fee01000 (reserved)
> (XEN) 00000000ffc00000 - 0000000100000000 (reserved)
> (XEN) 0000000100000000 - 00000001c0000000 (usable)
> (XEN) System RAM: 6135MB (6282404kB)
> (XEN) ACPI: RSDP 000F9C50, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BF790100, 0054 (r1 112608 XSDT1738 20081126 MSFT 97)
> (XEN) ACPI: FACP BF790290, 00F4 (r4 112608 FACP1738 20081126 MSFT 97)
> (XEN) ACPI: DSDT BF790470, 5AA5 (r2 1F380 1F380000 0 INTL 20051117)
> (XEN) ACPI: FACS BF79E000, 0040
> (XEN) ACPI: APIC BF790390, 0092 (r2 112608 APIC1738 20081126 MSFT 97)
> (XEN) ACPI: MCFG BF790430, 003C (r1 112608 OEMMCFG 20081126 MSFT 97)
> (XEN) ACPI: OEMB BF79E040, 0072 (r1 112608 OEMB1738 20081126 MSFT 97)
> (XEN) ACPI: DMAR BF79E0C0, 0118 (r1 AMI OEMDMAR 1 MSFT 97)
> (XEN) ACPI: SSDT BF7A0260, 1298 (r1 DpgPmm CpuPm 12 INTL 20051117)
> (XEN) Xen heap: 14MB (14536kB)
> (XEN) Domain heap initialised
> (XEN) Processor #0 7:10 APIC version 21
> (XEN) Processor #2 7:10 APIC version 21
> (XEN) Processor #4 7:10 APIC version 21
> (XEN) Processor #6 7:10 APIC version 21
> (XEN) Processor #1 7:10 APIC version 21
> (XEN) Processor #3 7:10 APIC version 21
> (XEN) Processor #5 7:10 APIC version 21
> (XEN) Processor #7 7:10 APIC version 21
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) [VT-D]dmar.c:372: RMRR is incorrect.
> (XEN) Intel VT-d has been enabled
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2660.058 MHz processor.
> (XEN) VMX: EPT is available.
> (XEN) VMX: VPID is available.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging detected.
> (XEN) CPU0: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 1/2 eip 8c000
> (XEN) CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 2/4 eip 8c000
> (XEN) CPU2: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 3/6 eip 8c000
> (XEN) CPU3: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 4/1 eip 8c000
> (XEN) CPU4: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 5/3 eip 8c000
> (XEN) CPU5: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 6/5 eip 8c000
> (XEN) CPU6: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Booting processor 7/7 eip 8c000
> (XEN) CPU7: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04
> (XEN) Total of 8 processors activated.
> (XEN) ENABLING IO-APIC IRQs
> (XEN) -> Using new ACK method
> (XEN) checking TSC synchronization across 8 CPUs: passed.
> (XEN) Platform timer is 3.579MHz ACPI PM Timer
> (XEN) Brought up 8 CPUs
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Xen kernel: 64-bit, lsb, compat32
> (XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 ->
> 0xffffffff805c190c
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN) Dom0 alloc.: 00000001b6000000->00000001b8000000 (1498227 pages
> to be allocated)
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN) Loaded kernel: ffffffff80200000->ffffffff805c190c
> (XEN) Init. ramdisk: ffffffff805c2000->ffffffff80b88200
> (XEN) Phys-Mach map: ffffffff80b89000->ffffffff81707398
> (XEN) Start info: ffffffff81708000->ffffffff817084a4
> (XEN) Page tables: ffffffff81709000->ffffffff81718000
> (XEN) Boot stack: ffffffff81718000->ffffffff81719000
> (XEN) TOTAL: ffffffff80000000->ffffffff81800000
> (XEN) ENTRY ADDRESS: ffffffff80200000
> (XEN) Dom0 has maximum 8 VCPUs
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three
times to switch
> input to Xen)
> (XEN) Freed 104kB init memory.
>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Hi Christian I checked the following spcifications. "Intel Virtualization Technology (Intel VT) for Directed I/O Architecture Specification" address=> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf As a result, DMAR ACPI TABLE of SUPERMICRO C7X58''s BIOS violates the specification. Here is the DMAR ACPI table: (I use acpidump command) DMAR @ 0xbf79e0c0 0000: 44 4d 41 52 18 01 00 00 01 92 41 4d 49 00 00 00 DMAR......AMI... 0010: 4f 45 4d 44 4d 41 52 00 01 00 00 00 4d 53 46 54 OEMDMAR.....MSFT 0020: 97 00 00 00 26 01 00 00 00 00 00 00 00 00 00 00 ....&........... 0030: 00 00 18 00 01 00 00 00 00 e0 ff fb 00 00 00 00 ................ 0040: 03 08 00 00 08 f0 1f 07 01 00 58 00 00 00 00 00 ..........X..... 0050: 00 c0 0e 00 00 00 00 00 ff ff 0e 00 00 00 00 00 ................ 0060: 01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01 ................ 0070: 01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07 ................ 0080: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01 ................ 0090: 01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07 ................ 00a0: 01 00 58 00 00 00 00 00 00 c0 7e bf 00 00 00 00 ..X.......~..... 00b0: ff bf 7e bf 00 00 00 00 01 08 00 00 00 00 1d 00 ..~............. 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 02 00 20 00 00 00 00 00 .......... ..... 0100: 02 08 00 00 00 00 01 00 02 08 00 00 00 00 03 00 ................ 0110: 02 08 00 00 00 00 07 00 ........ There are two Reserved Memory Region Reporting (RMRR) Structure in above DMAR ACPI TABLE. The 1st RMRR is correct( I think) , But the 2nd RMRR is incorrect. (Please look at page 75 of Intel''s specifications.) The RMRR Limit Address must be greater than the RMRR Base Adress. But, in my BIOS, RMRR Base Address is bf7ec000 and RMRR Limit Address is bf7ebfff. (RMRR Limit Address is smaller than RMRR Base Address !) Your ASUS P6T mother board and my board uses AMI BIOS. All AMI BIOS might be wrong in how to handle RMRR. I sent this report to SUPERMICRO Technical team. Thanks Yoshiharu Mori 2009/2/15 Christian Tramnitz <chris.ace@gmx.net>> Hello Yoshiharu-san! > > Have you tried 3.4-unstable yet? > I had the same problem with my Asus P6T Deluxe board (also X58) and got a > little further on 3.4 but finally (after some more RMRR and DMAR details > displayed) the same error message. > > It would be interesting to know if just the BIOSes (their DMAR maps to be > more specific) on non-Intel manufactured X58 boards are broken or if there > are general problems with X58 and Xen... has anyone gotten VTD/IOMMU to work > on X58 yet? > > Best regards, > Christian > > Yoshiharu Mori schrieb: > > >> 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 Xen, >> I can pass a PCI device through to Gest-OS(Windows XP) and have no problem >> with using the devices on Gest-OS. >> >> Is the above condition really correct and important ? >> >> xm dmesg results with deleting "return -EFAULT" are following. >> >> [root@localhost ~]# xm dmesg >> __ __ _____ _____ _ >> \ \/ /___ _ __ |___ / |___ / / | >> \ // _ \ ''_ \ |_ \ |_ \ | | >> / \ __/ | | | ___) | ___) || | >> /_/\_\___|_| |_| |____(_)____(_)_| >> >> (XEN) Xen version 3.3.1 (root@(none)) (gcc version 4.1.2 20071124 (Red >> Hat 4.1.2-42)) Sat Feb 14 05:21:09 JST 2009 >> (XEN) Latest ChangeSet: unavailable >> (XEN) Command line: iommu msi=1 >> (XEN) Video information: >> (XEN) VGA is text mode 80x25, font 8x16 >> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds >> (XEN) Disc information: >> (XEN) Found 0 MBR signatures >> (XEN) Found 2 EDD information structures >> (XEN) Xen-e820 RAM map: >> (XEN) 0000000000000000 - 0000000000099400 (usable) >> (XEN) 0000000000099400 - 00000000000a0000 (reserved) >> (XEN) 00000000000e0000 - 0000000000100000 (reserved) >> (XEN) 0000000000100000 - 00000000bf790000 (usable) >> (XEN) 00000000bf790000 - 00000000bf79e000 (ACPI data) >> (XEN) 00000000bf79e000 - 00000000bf7d0000 (ACPI NVS) >> (XEN) 00000000bf7d0000 - 00000000bf7e0000 (reserved) >> (XEN) 00000000bf7ec000 - 00000000c0000000 (reserved) >> (XEN) 00000000fee00000 - 00000000fee01000 (reserved) >> (XEN) 00000000ffc00000 - 0000000100000000 (reserved) >> (XEN) 0000000100000000 - 00000001c0000000 (usable) >> (XEN) System RAM: 6135MB (6282404kB) >> (XEN) ACPI: RSDP 000F9C50, 0024 (r2 ACPIAM) >> (XEN) ACPI: XSDT BF790100, 0054 (r1 112608 XSDT1738 20081126 MSFT >> 97) >> (XEN) ACPI: FACP BF790290, 00F4 (r4 112608 FACP1738 20081126 MSFT >> 97) >> (XEN) ACPI: DSDT BF790470, 5AA5 (r2 1F380 1F380000 0 INTL >> 20051117) >> (XEN) ACPI: FACS BF79E000, 0040 >> (XEN) ACPI: APIC BF790390, 0092 (r2 112608 APIC1738 20081126 MSFT >> 97) >> (XEN) ACPI: MCFG BF790430, 003C (r1 112608 OEMMCFG 20081126 MSFT >> 97) >> (XEN) ACPI: OEMB BF79E040, 0072 (r1 112608 OEMB1738 20081126 MSFT >> 97) >> (XEN) ACPI: DMAR BF79E0C0, 0118 (r1 AMI OEMDMAR 1 MSFT >> 97) >> (XEN) ACPI: SSDT BF7A0260, 1298 (r1 DpgPmm CpuPm 12 INTL >> 20051117) >> (XEN) Xen heap: 14MB (14536kB) >> (XEN) Domain heap initialised >> (XEN) Processor #0 7:10 APIC version 21 >> (XEN) Processor #2 7:10 APIC version 21 >> (XEN) Processor #4 7:10 APIC version 21 >> (XEN) Processor #6 7:10 APIC version 21 >> (XEN) Processor #1 7:10 APIC version 21 >> (XEN) Processor #3 7:10 APIC version 21 >> (XEN) Processor #5 7:10 APIC version 21 >> (XEN) Processor #7 7:10 APIC version 21 >> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 >> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs >> (XEN) [VT-D]dmar.c:372: RMRR is incorrect. >> (XEN) Intel VT-d has been enabled >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) Detected 2660.058 MHz processor. >> (XEN) VMX: EPT is available. >> (XEN) VMX: VPID is available. >> (XEN) HVM: VMX enabled >> (XEN) HVM: Hardware Assisted Paging detected. >> (XEN) CPU0: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 1/2 eip 8c000 >> (XEN) CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 2/4 eip 8c000 >> (XEN) CPU2: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 3/6 eip 8c000 >> (XEN) CPU3: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 4/1 eip 8c000 >> (XEN) CPU4: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 5/3 eip 8c000 >> (XEN) CPU5: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 6/5 eip 8c000 >> (XEN) CPU6: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Booting processor 7/7 eip 8c000 >> (XEN) CPU7: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 >> (XEN) Total of 8 processors activated. >> (XEN) ENABLING IO-APIC IRQs >> (XEN) -> Using new ACK method >> (XEN) checking TSC synchronization across 8 CPUs: passed. >> (XEN) Platform timer is 3.579MHz ACPI PM Timer >> (XEN) Brought up 8 CPUs >> (XEN) I/O virtualisation enabled >> (XEN) I/O virtualisation for PV guests disabled >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) [VT-D]iommu.c:1269:d32767 domain_context_mapping:invalid >> (XEN) *** LOADING DOMAIN 0 *** >> (XEN) Xen kernel: 64-bit, lsb, compat32 >> (XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> >> 0xffffffff805c190c >> (XEN) PHYSICAL MEMORY ARRANGEMENT: >> (XEN) Dom0 alloc.: 00000001b6000000->00000001b8000000 (1498227 pages to >> be allocated) >> (XEN) VIRTUAL MEMORY ARRANGEMENT: >> (XEN) Loaded kernel: ffffffff80200000->ffffffff805c190c >> (XEN) Init. ramdisk: ffffffff805c2000->ffffffff80b88200 >> (XEN) Phys-Mach map: ffffffff80b89000->ffffffff81707398 >> (XEN) Start info: ffffffff81708000->ffffffff817084a4 >> (XEN) Page tables: ffffffff81709000->ffffffff81718000 >> (XEN) Boot stack: ffffffff81718000->ffffffff81719000 >> (XEN) TOTAL: ffffffff80000000->ffffffff81800000 >> (XEN) ENTRY ADDRESS: ffffffff80200000 >> (XEN) Dom0 has maximum 8 VCPUs >> (XEN) Scrubbing Free RAM: .done. >> (XEN) Xen trace buffers: disabled >> (XEN) Std. Loglevel: Errors and warnings >> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >> (XEN) Xen is relinquishing VGA console. >> (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input >> to Xen) >> (XEN) Freed 104kB init memory. >> >> >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello Yoshiharu-san
you are right, the DMRR is screwed for me to, I have the same address
violation than you.
I already contacted Asus Support and they came back and told me that
Linux is not officially supported so they can do nothing about it.
I''ll probably return the board to the distributor and get an
Intel-board
instead... <sigh>
Hope you have better luck with Supermicro.
Best regards,
Christian
Yoshiharu Mori schrieb:> Hi Christian
>
> I checked the following spcifications.
>
> "Intel Virtualization Technology (Intel VT) for Directed I/O
> Architecture Specification"
> address=>
>
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>
> As a result, DMAR ACPI TABLE of SUPERMICRO C7X58''s BIOS violates
the
> specification.
>
> Here is the DMAR ACPI table: (I use acpidump command)
>
> DMAR @ 0xbf79e0c0
> 0000: 44 4d 41 52 18 01 00 00 01 92 41 4d 49 00 00 00 DMAR......AMI...
> 0010: 4f 45 4d 44 4d 41 52 00 01 00 00 00 4d 53 46 54 OEMDMAR.....MSFT
> 0020: 97 00 00 00 26 01 00 00 00 00 00 00 00 00 00 00
....&...........
> 0030: 00 00 18 00 01 00 00 00 00 e0 ff fb 00 00 00 00 ................
> 0040: 03 08 00 00 08 f0 1f 07 01 00 58 00 00 00 00 00 ..........X.....
> 0050: 00 c0 0e 00 00 00 00 00 ff ff 0e 00 00 00 00 00 ................
> 0060: 01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01 ................
> 0070: 01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07 ................
> 0080: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01 ................
> 0090: 01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07 ................
> 00a0: 01 00 58 00 00 00 00 00 00 c0 7e bf 00 00 00 00 ..X.......~.....
> 00b0: ff bf 7e bf 00 00 00 00 01 08 00 00 00 00 1d 00 ..~.............
> 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................
> 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................
> 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................
> 00f0: 01 08 00 00 00 00 1a 07 02 00 20 00 00 00 00 00 .......... .....
> 0100: 02 08 00 00 00 00 01 00 02 08 00 00 00 00 03 00 ................
> 0110: 02 08 00 00 00 00 07 00 ........
>
> There are two Reserved Memory Region Reporting (RMRR) Structure in above
> DMAR ACPI TABLE.
> The 1st RMRR is correct( I think) , But the 2nd RMRR is incorrect.
> (Please look at page 75 of Intel''s specifications.)
>
> The RMRR Limit Address must be greater than the RMRR Base Adress.
> But, in my BIOS, RMRR Base Address is bf7ec000 and RMRR Limit Address is
> bf7ebfff.
> (RMRR Limit Address is smaller than RMRR Base Address !)
>
> Your ASUS P6T mother board and my board uses AMI BIOS.
> All AMI BIOS might be wrong in how to handle RMRR.
>
> I sent this report to SUPERMICRO Technical team.
>
> Thanks
>
> Yoshiharu Mori
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
I would recommend opening a new ticket with ASUS and telling them
you were running Windows if you can get the same output Yoshiharu-san did
and it fails to meet AMD specifications the way his fails to meet Intel
specifications, after all, that would mean their board was out of spec with
AMD, not Linux. However, in my experience, ASUS can''t fix anything (I
tried
to be an early adopter of the SiI port multiplier via their P5WD2-Premium
onboard SiI SATA and a port multiplier from someone else, after all, their
documentation clearly stated that they supported port multipliers, and they
didn''t make their own, however, it wouldn''t work with port
multipliers, they
"escalated it to their engineering," and I never heard back, so the
issue
was never resolved). I''d recommend going with Gigabyte or SuperMicro,
because I''ve had equally bad support from MSI (I have several computers
whose systems monitoring software goes off continuously until reboot after
using a floppy drive, that would have to be a firmware issue, and they
can''t
fix it). All the other manufacturers are either awfully new to the market
or awfully unreliable (Biostar, for instance, isn''t likely to have a
board
last much longer than their warranty in my experience, regardless of
platform), SuperMicro would probably be the better bet compatibility wise,
but they have a short warranty and less features (read: less additional
features that probably don''t work with Linux anyway). Good luck
finding
something that works, be sure to let everyone know what it is.
Dustin
-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Christian
Tramnitz
Sent: Tuesday, February 17, 2009 02:33
To: xen-users@lists.xensource.com
Subject: [Xen-users] Re: VT-D RMRR is incorrect
Hello Yoshiharu-san
you are right, the DMRR is screwed for me to, I have the same address
violation than you.
I already contacted Asus Support and they came back and told me that
Linux is not officially supported so they can do nothing about it.
I''ll probably return the board to the distributor and get an
Intel-board
instead... <sigh>
Hope you have better luck with Supermicro.
Best regards,
Christian
Yoshiharu Mori schrieb:> Hi Christian
>
> I checked the following spcifications.
>
> "Intel Virtualization Technology (Intel VT) for Directed I/O
> Architecture Specification"
> address=>
>
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct
_IO.pdf>
> As a result, DMAR ACPI TABLE of SUPERMICRO C7X58''s BIOS violates
the
> specification.
>
> Here is the DMAR ACPI table: (I use acpidump command)
>
> DMAR @ 0xbf79e0c0
> 0000: 44 4d 41 52 18 01 00 00 01 92 41 4d 49 00 00 00 DMAR......AMI...
> 0010: 4f 45 4d 44 4d 41 52 00 01 00 00 00 4d 53 46 54 OEMDMAR.....MSFT
> 0020: 97 00 00 00 26 01 00 00 00 00 00 00 00 00 00 00
....&...........
> 0030: 00 00 18 00 01 00 00 00 00 e0 ff fb 00 00 00 00 ................
> 0040: 03 08 00 00 08 f0 1f 07 01 00 58 00 00 00 00 00 ..........X.....
> 0050: 00 c0 0e 00 00 00 00 00 ff ff 0e 00 00 00 00 00 ................
> 0060: 01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01 ................
> 0070: 01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07 ................
> 0080: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01 ................
> 0090: 01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07 ................
> 00a0: 01 00 58 00 00 00 00 00 00 c0 7e bf 00 00 00 00 ..X.......~.....
> 00b0: ff bf 7e bf 00 00 00 00 01 08 00 00 00 00 1d 00 ..~.............
> 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................
> 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................
> 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................
> 00f0: 01 08 00 00 00 00 1a 07 02 00 20 00 00 00 00 00 .......... .....
> 0100: 02 08 00 00 00 00 01 00 02 08 00 00 00 00 03 00 ................
> 0110: 02 08 00 00 00 00 07 00 ........
>
> There are two Reserved Memory Region Reporting (RMRR) Structure in above
> DMAR ACPI TABLE.
> The 1st RMRR is correct( I think) , But the 2nd RMRR is incorrect.
> (Please look at page 75 of Intel''s specifications.)
>
> The RMRR Limit Address must be greater than the RMRR Base Adress.
> But, in my BIOS, RMRR Base Address is bf7ec000 and RMRR Limit Address is
> bf7ebfff.
> (RMRR Limit Address is smaller than RMRR Base Address !)
>
> Your ASUS P6T mother board and my board uses AMI BIOS.
> All AMI BIOS might be wrong in how to handle RMRR.
>
> I sent this report to SUPERMICRO Technical team.
>
> Thanks
>
> Yoshiharu Mori
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Dustin,
I couldn''t really get what you were trying to say (I never mentioned
AMD...) but anyway this isn''t really Linux specific it''s a
BIOS bug.
Unfortunately the only way to get in contact with that bug is to either
use Xen or enable DMRR in the vanilla Linux kernel. If this cannot be
fixed in software I''ll probably return the board to the store and get
an
Intel DX58SO instead...
Yoshiharu, have you tested Xen-unstable yet? When commenting out the
EFAULT you mentioned I get an immediate panic related to the rmrr
address conflict on the latest 3.4-unstable tree.
@Xen devs: Is this something that could be worked around in Xen or do we
really have to rely on exact RMRR values for vtd to work?
See http://permalink.gmane.org/gmane.comp.emulators.xen.user/43937 for
more details.
Thanks,
Christian
Dustin Henning schrieb:> I would recommend opening a new ticket with ASUS and telling them
> you were running Windows if you can get the same output Yoshiharu-san did
> and it fails to meet AMD specifications the way his fails to meet Intel
> specifications, after all, that would mean their board was out of spec with
> AMD, not Linux. However, in my experience, ASUS can''t fix
anything (I tried
> to be an early adopter of the SiI port multiplier via their P5WD2-Premium
> onboard SiI SATA and a port multiplier from someone else, after all, their
> documentation clearly stated that they supported port multipliers, and they
> didn''t make their own, however, it wouldn''t work with
port multipliers, they
> "escalated it to their engineering," and I never heard back, so
the issue
> was never resolved). I''d recommend going with Gigabyte or
SuperMicro,
> because I''ve had equally bad support from MSI (I have several
computers
> whose systems monitoring software goes off continuously until reboot after
> using a floppy drive, that would have to be a firmware issue, and they
can''t
> fix it). All the other manufacturers are either awfully new to the market
> or awfully unreliable (Biostar, for instance, isn''t likely to have
a board
> last much longer than their warranty in my experience, regardless of
> platform), SuperMicro would probably be the better bet compatibility wise,
> but they have a short warranty and less features (read: less additional
> features that probably don''t work with Linux anyway). Good luck
finding
> something that works, be sure to let everyone know what it is.
> Dustin
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Hi Christian> Yoshiharu, have you tested Xen-unstable yet? When commenting out the EFAULT > you mentioned I get an immediate panic related to the rmrr address conflict > on the latest 3.4-unstable tree.I also tried Xen-unstable, but could not boot xen when I commented out the EFAULT. (The boot message was too fast and my machine was rebooted soon, I counldn''t understand details.) BTW, I got new BIOS from SUPERMICRO. But I cannot test till next week end. Another trouble was happend on my board, I sent it to distributor and change it. @Xen devs: Is this something that could be worked around in Xen or do we> really have to rely on exact RMRR values for vtd to work? > See http://permalink.gmane.org/gmane.comp.emulators.xen.user/43937 for > more details.The RMRR regions are expencted to be used only for USB and UMA Graphics legacy usages for reserved memory, I think it may be possible to use vtd with limitation. Thanks, Yoshiharu Mori _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross Philipson
2009-Feb-21 17:14 UTC
RE: [Xen-devel] Re: [Xen-users] Re: VT-D RMRR is incorrect
Hi folks, This sounds a lot like an issue I am working on right now. A recent change to the vtd code changed the way the 1 to 1 page mapping for dom0 is done (look at intel_iommu_domain_init() for dom0). The change was to query the e820 map for memory regions that were usable RAM and only map those into the iommus for dom0. Thus reserved regions were no longer mapped in. When the RMRR values do not report the correct values for required 1 to 1 reserved memory regions, the needed regions do not get mapped in. Thus device DMA to these regions causes vtd faults and in out case a hang. It is indeed a BIOS bug; perhaps this is the same issue you are seeing? Anyway, I am working on a workaround that I will be pushing upstream this week. A parameter will allow you to include reserved memory regions in the mappings. It is not ideal (less secure) but better than hanging or crashing... Thanks Ross From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yoshiharu Mori Sent: Saturday, February 21, 2009 11:58 AM To: Christian Tramnitz Cc: xen-devel@lists.xensource.com; xen-users@lists.xensource.com Subject: [Xen-devel] Re: [Xen-users] Re: VT-D RMRR is incorrect Hi Christian Yoshiharu, have you tested Xen-unstable yet? When commenting out the EFAULT you mentioned I get an immediate panic related to the rmrr address conflict on the latest 3.4-unstable tree. I also tried Xen-unstable, but could not boot xen when I commented out the EFAULT. (The boot message was too fast and my machine was rebooted soon, I counldn''t understand details.) BTW, I got new BIOS from SUPERMICRO. But I cannot test till next week end. Another trouble was happend on my board, I sent it to distributor and change it. @Xen devs: Is this something that could be worked around in Xen or do we really have to rely on exact RMRR values for vtd to work? See http://permalink.gmane.org/gmane.comp.emulators.xen.user/43937 for more details. The RMRR regions are expencted to be used only for USB and UMA Graphics legacy usages for reserved memory, I think it may be possible to use vtd with limitation. Thanks, Yoshiharu Mori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian,
I am not sure what lead me to believe you had an AMD system. To
summarize what I was trying to say, ASUS is claiming that this issue is
unsupported because you use Linux, but at the end of the day, the issue has
nothing to do with Linux directly (any virtualization software that used
VT-D could have the same problem, including those run on Windows.
Therefore, if you tell ASUS that you are running Windows and then tell them
that your issue is that their BIOS doesn''t meet Intel''s
specifications, then
you might be able to get the case escalated (not that anyone at ASUS could
ever get it fixed), and if it were resolved, this would be good for the Xen
community. Barring that, especially if you are in a hurry to get this
working, going with an Intel board should be a safe bet. I mentioned my
thoughts on some other motherboard manufacturers as well, and I must redact
one of those, based on a thread I read this morning, Gigabyte motherboards
don''t even support VT-D (or at least Gigabyte had no intention of
supporting
it not too long ago), see this thread:
http://lists.xensource.com/archives/html/xen-users/2009-02/msg00630.html.
Good luck,
Dustin
-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Christian
Tramnitz
Sent: Saturday, February 21, 2009 10:31
To: xen-users@lists.xensource.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-users] Re: VT-D RMRR is incorrect
Dustin,
I couldn''t really get what you were trying to say (I never mentioned
AMD...) but anyway this isn''t really Linux specific it''s a
BIOS bug.
Unfortunately the only way to get in contact with that bug is to either
use Xen or enable DMRR in the vanilla Linux kernel. If this cannot be
fixed in software I''ll probably return the board to the store and get
an
Intel DX58SO instead...
Yoshiharu, have you tested Xen-unstable yet? When commenting out the
EFAULT you mentioned I get an immediate panic related to the rmrr
address conflict on the latest 3.4-unstable tree.
@Xen devs: Is this something that could be worked around in Xen or do we
really have to rely on exact RMRR values for vtd to work?
See http://permalink.gmane.org/gmane.comp.emulators.xen.user/43937 for
more details.
Thanks,
Christian
Dustin Henning schrieb:> I would recommend opening a new ticket with ASUS and telling them
> you were running Windows if you can get the same output Yoshiharu-san did
> and it fails to meet AMD specifications the way his fails to meet Intel
> specifications, after all, that would mean their board was out of spec
with> AMD, not Linux. However, in my experience, ASUS can''t fix
anything (I
tried> to be an early adopter of the SiI port multiplier via their P5WD2-Premium
> onboard SiI SATA and a port multiplier from someone else, after all, their
> documentation clearly stated that they supported port multipliers, and
they> didn''t make their own, however, it wouldn''t work with
port multipliers,
they> "escalated it to their engineering," and I never heard back, so
the issue
> was never resolved). I''d recommend going with Gigabyte or
SuperMicro,
> because I''ve had equally bad support from MSI (I have several
computers
> whose systems monitoring software goes off continuously until reboot after
> using a floppy drive, that would have to be a firmware issue, and they
can''t> fix it). All the other manufacturers are either awfully new to the market
> or awfully unreliable (Biostar, for instance, isn''t likely to have
a board
> last much longer than their warranty in my experience, regardless of
> platform), SuperMicro would probably be the better bet compatibility wise,
> but they have a short warranty and less features (read: less additional
> features that probably don''t work with Linux anyway). Good luck
finding
> something that works, be sure to let everyone know what it is.
> Dustin
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On Tue, Feb 24, 2009 at 12:36 AM, Dustin Henning <Dustin.Henning@prd-inc.com> wrote:> Christian, > I am not sure what lead me to believe you had an AMD system. To > summarize what I was trying to say, ASUS is claiming that this issue is > unsupported because you use Linux, but at the end of the day, the issue has > nothing to do with Linux directly (any virtualization software that used > VT-D could have the same problem, including those run on Windows.Well this should be easy to resolve... can anyone tell me what Windows virtualisation software supports VT-D ?? it would be no problem for me to put another drive in my P6T with windows on it and test it out..... that way I can log a case about it not working. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christian Tramnitz
2009-Feb-25 22:26 UTC
[Xen-devel] Re: [Xen-users] Re: VT-D RMRR is incorrect
Ross Philipson schrieb:> Hi folks, > > This sounds a lot like an issue I am working on right now. A recent > change to the vtd code changed the way the 1 to 1 page mapping for dom0 > is done (look at intel_iommu_domain_init() for dom0). The change was to > query the e820 map for memory regions that were usable RAM and only map > those into the iommus for dom0. Thus reserved regions were no longer > mapped in. When the RMRR values do not report the correct values for > required 1 to 1 reserved memory regions, the needed regions do not get > mapped in. Thus device DMA to these regions causes vtd faults and in out > case a hang. It is indeed a BIOS bug; perhaps this is the same issue you > are seeing? > > Anyway, I am working on a workaround that I will be pushing upstream > this week. A parameter will allow you to include reserved memory regions > in the mappings. It is not ideal (less secure) but better than hanging > or crashing…Hi Ross, I tried your patch from you other post, but even with the new parameter enabled I still get the DMAR error messages and vt-d being disabled: (XEN) Command line: dom0_mem=1024M iommu=1 iommu_include_reserved=1 ... (XEN) [VT-D]dmar.c:473: Host address width 39 (XEN) [VT-D]dmar.c:482: found ACPI_DMAR_DRHD (XEN) [VT-D]dmar.c:337: dmaru->address = fbfff000 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1b.0 (XEN) [VT-D]dmar.c:482: found ACPI_DMAR_DRHD (XEN) [VT-D]dmar.c:337: dmaru->address = fbffe000 (XEN) [VT-D]dmar.c:294: found IOAPIC: bdf = f0:1f.7 (XEN) [VT-D]dmar.c:294: found IOAPIC: bdf = 0:13.0 (XEN) [VT-D]dmar.c:346: found INCLUDE_ALL (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.0 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.1 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.2 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.7 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1a.0 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1a.1 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1a.2 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1a.7 (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address bf7dbfff (XEN) Failed to parse ACPI DMAR. Disabling VT-d. Best regards, Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR > (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address > bf7dbfffThis is a shot-in-the-dark guess: Is there some way to treat an entry like this as if it wasn''t there at all? Theory: If some BIOS programmer set aside two records to be used for various needs, and then on boot detected that one of them wasn''t needed (say, integrated graphics not present, so 0 MB reserved?), perhaps said BIOS programmer would just set the range to be 0 bytes, rather than go through the effort to remove the entire record? What could go wrong if the parser just treated entries mapping 0 byte ranges (like this one) as if they didn''t exist? -- View this message in context: http://www.nabble.com/VT-D-RMRR-is-incorrect-tp22005500p22423800.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
> (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR > (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address > bf7dbfffThis is a shot-in-the-dark guess: Is there some way to treat an entry like this as if it wasn''t there at all? Theory: If some BIOS programmer set aside two records to be used for various needs, and then on boot detected that one of them wasn''t needed (say, integrated graphics not present, so 0 MB reserved?), perhaps said BIOS programmer would just set the range to be 0 bytes, rather than go through the effort to remove the entire record? What could go wrong if the parser just treated entries mapping 0 byte ranges (like this one) as if they didn''t exist? Christian Tramnitz wrote:> > Ross Philipson schrieb: > >> Anyway, I am working on a workaround that I will be pushing upstream >> this week. A parameter will allow you to include reserved memory regions >> in the mappings. It is not ideal (less secure) but better than hanging >> or crashing… > > > Hi Ross, > > I tried your patch from you other post, but even with the new parameter > enabled I still get the DMAR error messages and vt-d being disabled: > > (XEN) Command line: dom0_mem=1024M iommu=1 iommu_include_reserved=1 > ... > (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR > (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address > bf7dbfff > (XEN) Failed to parse ACPI DMAR. Disabling VT-d. > > > Best regards, > Christian > > >-- View this message in context: http://www.nabble.com/VT-D-RMRR-is-incorrect-tp22005500p22479357.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