similar to: Success: VT-d on ASUS P6T

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:

Trying to set up PCI pass through with xen 3.2.1 on Debian Lenny, with xen Kernel 2.6.26... having no luck. I have the following configured... i) Virtualization and vt-d are both enabled in the bios, I have power cycled after making these changes. ii) I have these option in grub menu; iommu=1 pciback.permissive pciback.hide=(07:01.0)(01:00.0) vtd=1 iii) I have this in my cfg file

Hi, I have an ASUS P6T Deluxe and I''m trying to use VT-d with Xen. I have also tried it with ESXi and Parallels Workstation Extreme - none of them work correctly. >From reading the xen-user and xen-devel list archives, I see that this motherboard has problems with malformed DMAR tables. Is there anything I can do to fix/workaround this or am I completely stuck? I did notice

reaver wrote: > > 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

tmoore wrote: > > > I`ve raised a support case with ASUS to try to get them to fix the BIOS on > P6T Deluxe ... I`ll keep this thread updated. > > The IOMMU is seriously broken on 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

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

Hi folks, currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board to a HVM domU. Unfortunate there seem some issue with the VT-d DMAR tables which is beyond my knowledge and

I searched the net and I found this. So, it looks like it doesn''t quite work. http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00382.html Does it work now? Also, what is RMRR? I guess Asus doesn''t support Linux? brian -- Brian Lavender http://www.brie.com/brian/ "Program testing can be used to show the presence of bugs, but never to show their absence!"

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

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

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

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

I have a chipset which supports VT-d (Intel X58) and, according to my motherboard manufacturers, VT-d is enabled in the BIOS and listed as "Intel VT." The problem is that xm dmesg shows "I/O virtualisation disabled" and I get this error message when I try to create a domU with a pci device assigned: ''Error: failed to assign device: maybe the platform doesn''t

Good day to you Im a casual Xen user and am also using I/O Virtualization. I had always trouble getting DMAR tables (and IOMMU) recognized with Asus Mainboards, despite the fact that I always used this boards a lot. Since the Nehalem Intel architecture, I looked into Intel Mainboards due the fact that this seems to work out with Xen, Linux and VT-d. My request is, that someone who tried Asus

OK, cut two of the iommu reserved memory issue patch as we discussed... This patch adds a boolean boot parameter to xen to allow inclusive mapping of all memory below 4GB to the iommu mappings for dom0. The unusable ranges and memory occupied by xen are still excluded. The parameter is "iommu_inclusive_mapping=1" and is off by default. In addition to the parameter, a warning is also

Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is pointless. Signed-off-by: Tom Murphy <murphyt7 at tcd.ie> --- drivers/iommu/intel-iommu.c | 89

Hi all, Thought I''d share my success with VT-d. I picked up an Asus P5E-VM DO motherboard as it was relatively cheap and had an extra PCI slot compared to the Intel Q35 board. The people on #xen IRC were very helpful. I wasted 2 days trying to get things working on Ubuntu and OpenSUSE with forward patched versions of Xen for newer kernels. Ended up using CentOS 5.1 which has the requred

I'm looking at setting up a new machine to run CentOS 5 and a few VMWare machines to test Windows XP, Vista, and 7. I'm working with a custom PC shop and they've recommended I use either the ASUS PT6 or Intel DX58SO. Any feedback good or bad on either of these? Thanks! --Chris

Greetings, I''m attempting to do gfx_passthru with the primary graphics adapter (03:00.0), passing it to a guest. I can unbind it from the host but when I fire up the guest OS my monitor loses signal from the graphics card and that''s that. The GFX card is dual DVI, I''ve tried both slots. Host is Linux 2.6.32.14-1.2.105.xendom0.fc12.x86_64, Guest is Windows 7. PC is an