Hi TheWiz,
I´ve already tried every option related to virtualiziation, and flashed every available BIOS provided by Asus up and down. VT-d is defintily enabled, and also working for every device without RMRR entries.
Here is a part of my bootlog, what xen says about the dmar table:
Quote:(XEN) [VT-D]dmar.c:686: Host address width 39
(XEN) [VT-D]dmar.c:701: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398: dmaru->address = fbffe000
(XEN) [VT-D]iommu.c:1082: drhd->address = fbffe000 iommu->reg = ffff82c3fff57000
(XEN) [VT-D]iommu.c:1084: cap = c90780106f0462 ecap = f020fe
(XEN) [VT-D]dmar.c:341: IOAPIC: f0:1f.7
(XEN) [VT-D]dmar.c:341: IOAPIC: 0:13.0
(XEN) [VT-D]dmar.c:412: flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:706: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.1
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.2
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.7
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.1
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.2
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.7
(XEN) [VT-D]dmar.c:578: RMRR region: base_addr ec000 end_address effff
(XEN) [VT-D]dmar.c:706: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:512: RMRR address range not in reserved memory base = bf7dc000 end = bf7dbfff; iommu_inclusive_mapping=1 parameter may be needed.
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.1
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.2
(XEN) [VT-D]dmar.c:335: endpoint: 0:1d.7
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.1
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.2
(XEN) [VT-D]dmar.c:335: endpoint: 0:1a.7
(XEN) [VT-D]dmar.c:569: The RMRR (bf7dc000, bf7dbfff) is incorrect!
(XEN) [VT-D]dmar.c:711: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:606: atsru->all_ports: 0
(XEN) [VT-D]dmar.c:321: bridge: 0:1.0 start = 0 sec = 1 sub = 1
(XEN) [VT-D]dmar.c:321: bridge: 0:3.0 start = 0 sec = 2 sub = 2
(XEN) [VT-D]dmar.c:321: bridge: 0:7.0 start = 0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:321: bridge: 0:9.0 start = 0 sec = 4 sub = 4
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
As you can see, in the second range the start-address is greater than the end-address.
Only with commenting out the security shutdown in the source i´ve got VT-d to be enabled. The mentioned iommu_inclusive_mapping=1 parameter is set, but makes no difference.
In the xen-wiki they write about a modded unofficial BIOS, where this issue is fixed for the P6T Deluxe. Unfortunatly google didn´t tell me where to find it. (Not for flashing my board to death, just to provide you as much marterial as possible)
Quote: ASUS P6T Deluxe (Intel X58 chipset) requires (currently non-public) BIOS update to correct DMAR-table issue
http://wiki.xensource.com/xenwiki/VTdHowTo
So correcting this dmar entries seems to me the last chance to get rid of those nasty system freezes, when having high I/O over the usb controller passed trough (as you can see in the xen log, the two usb controllers, 00:1d.x and 001a.x, are the only devices with entries), like from webcam or external disks.
This are the Intel spec´s of the memory range found in
ftp://download.intel.com/technology/comp...ect_IO.pdf :
Quote:The interrupt-remapping architecture enables system software to control and censor external
interrupt requests generated by all sources including those from interrupt controllers (I/OxAPICs),
MSI/MSI-X capable devices including endpoints, root-ports and Root-Complex integrated end-points.
Interrupts generated by the remapping hardware itself (Fault Event and Invalidation Completion
Events) are not subject to interrupt remapping.
Interrupt requests appear to the Root-Complex as upstream memory write requests to the interruptaddress-
range 0xFEEX_XXXXh. Since interrupt requests arrive at the Root-Complex as write requests,
interrupt-remapping is co-located with the DMA-remapping hardware units. The interrupt-remapping
capability is reported through the Extended Capability register.
Greetz,
Bunkasan