From mboxrd@z Thu Jan  1 00:00:00 1970
From: Felix Kuperjans <felix@desaster-games.com>
Subject: About VT-d on ASUS P6T
Date: Tue, 11 May 2010 12:09:27 +0200
Message-ID: <4BE92CD7.1080205@desaster-games.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

Hi,

as I posted on xen-users, I've successfully used pci passtrough on an ASUS P6T mainboard which is known to have really buggy RMRR tables.

I needed the iommu=passtrough and iommu_inclusive_mapping=1 command line options, combined with a little change to the RMRR parsing code:

dmar.c:

@@ -559,8 +558,7 @@
             dprintk(XENLOG_WARNING VTDPREFIX,
                 "  The RMRR (%"PRIx64", %"PRIx64") is incorrect!\n",
                 rmrru->base_address, rmrru->end_address);
-            xfree(rmrru);
-            ret = -EFAULT;
+            acpi_register_rmrr_unit(rmrru);
         }
         else
         {

This way, the condition that causes the error printed above, does not lead to an abortion of VT-d code, but instead registers the RMRR unit as if it was correct.
VT-d is working properly afterwards and I've tested some devices successfully.

Probably, you would prefer to choose the action based on some command line option (like iommu_inclusive_mapping=1) instead of ignoring this error by default.

Regards,
Felix