xen-devel
Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table |
From: |
Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx> |
Date: |
Mon, 14 Jul 2008 14:21:04 +0100 |
Cc: |
"Zhao, Yu" <yu.zhao@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Han, Weidong" <weidong.han@xxxxxxxxx>, Neo Jia <neojia@xxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxxxxxx> |
Delivery-date: |
Mon, 14 Jul 2008 06:22:02 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C4A0BB5A.1AF3C%keir.fraser@xxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<5d649bdb0807132347y23d19142n4f07eacb16d0845e@xxxxxxxxxxxxxx> <C4A0BB5A.1AF3C%keir.fraser@xxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
[Keir Fraser]
> On 14/7/08 07:47, "Neo Jia" <neojia@xxxxxxxxx> wrote:
>> In line: 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00, the RMRR
>> reserved memory region starting address is even higher than its limit
>> address.
>>
>> Is there anyway to do a software workaround for this issue? I tried
>> to simply ignore that entry in the "acpi_parse_one_rmrr" function,
>> but I hit a panic in function "iommu_enable_translation".
> This kind of thing makes me quite uneasy about enabling VT-d by
> default in Xen 3.3. I¹m quite tempted to require ?iommu¹ on the
> command line to enable it.
I've had ACPI problems with the Dell T7400 as well. Using an
unpatched Xen caused the system to hangup during startup. Dell only
managed to release a BIOS upgrade that fixed the problem less than two
weeks ago.
Anyhow, the very least one should do is to disable VT-d if parsing the
ACPI DMAR fails. I've attached a patch which does this. It's then
only a matter of returning an error if any of the DMAR tables look
suspicious.
eSk
--
vt-d: Disable VT-d if parsing ACPI DMAR fails
Signed-off-by: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
diff -r b80d6639cad4 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Mon Jul 14 12:54:37 2008 +0100
+++ b/xen/drivers/passthrough/vtd/dmar.c Mon Jul 14 14:12:40 2008 +0100
@@ -82,6 +82,29 @@ static int __init acpi_register_rmrr_uni
{
list_add(&rmrr->list, &acpi_rmrr_units);
return 0;
+}
+
+static void __init disable_all_dmar_units(void)
+{
+ struct acpi_drhd_unit *drhd, *_drhd;
+ struct acpi_rmrr_unit *rmrr, *_rmrr;
+ struct acpi_atsr_unit *atsr, *_atsr;
+
+ list_for_each_entry_safe ( drhd, _drhd, &acpi_drhd_units, list )
+ {
+ list_del(&drhd->list);
+ xfree(drhd);
+ }
+ list_for_each_entry_safe ( rmrr, _rmrr, &acpi_rmrr_units, list )
+ {
+ list_del(&rmrr->list);
+ xfree(rmrr);
+ }
+ list_for_each_entry_safe ( atsr, _atsr, &acpi_atsr_units, list )
+ {
+ list_del(&atsr->list);
+ xfree(atsr);
+ }
}
static int acpi_ioapic_device_match(
@@ -436,6 +459,12 @@ static int __init acpi_parse_dmar(struct
/* Zap APCI DMAR signature to prevent dom0 using vt-d HW. */
dmar->header.signature[0] = '\0';
+ if ( ret )
+ {
+ printk(XENLOG_WARNING "Failed to parse ACPI DMAR. Disabling VT-d.\n");
+ disable_all_dmar_units();
+ }
+
return ret;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|