Your code changes just let xen not disable VT-d, but actually
"iommu=passthrough" avoids problems of incorrect RMRR. This option makes dom0
not use VT-d, therefore incorrect RMRR won't be used by device. But if you
assign the device whose RMRR incorrect to guest, it still causes problems.
Regards,
Weidong
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Felix Kuperjans
Sent: Tuesday, May 11, 2010 6:09 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] About VT-d on ASUS P6T
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home