Neo Jia
2008-Jul-14 06:47 UTC
[Xen-devel] Workaround for the corrupted Intel X48 DMAR table
hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jul-14 07:14 UTC
Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
On 14/7/08 07:47, "Neo Jia" <neojia@gmail.com> 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-14 07:59 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-14 09:01 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
Neo, Can you try attached patch? I guess you are using add-on graphics card, right? Randy (weidong) ________________________________ From: Han, Weidong Sent: 2008年7月14日 16:00 To: ''Neo Jia''; ''xen-devel@lists.xensource.com'' Cc: Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Espen Skoglund
2008-Jul-14 13:21 UTC
Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
[Keir Fraser]> On 14/7/08 07:47, "Neo Jia" <neojia@gmail.com> 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@netronome.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Neo Jia
2008-Jul-14 19:02 UTC
[Xen-devel] Re: Workaround for the corrupted Intel X48 DMAR table
Randy, I just tried your patch, which is almost same as mine to ignore those incorrect RMRR entries. Here is the screenshot of the panic, as there is no onboard serial port. Thanks, Neo On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote:> Neo, > > Can you try attached patch? I guess you are using add-on graphics card, > right? > > Randy (weidong) > > ------------------------------ > *From:* Han, Weidong > *Sent:* 2008年7月14日 16:00 > *To:* 'Neo Jia'; 'xen-devel@lists.xensource.com' > *Cc:* Zhao, Yu; 'Jean Guyader' > *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table > > It should be a BIOS bug. > > Can you post your changes in "acpi_parse_one_rmrr" function and panic > information? > > Randy (Weidong) > > ------------------------------ > *From:* Neo Jia [mailto:neojia@gmail.com] > *Sent:* 2008年7月14日 14:48 > *To:* xen-devel@lists.xensource.com > *Cc:* Han, Weidong; Zhao, Yu; Jean Guyader > *Subject:* Workaround for the corrupted Intel X48 DMAR table > > hi, > > I am trying the Xen unstable on X48 chipset these days but it failed due to > an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. > > DMAR @ 0x7fef1000 > 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL > 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT > 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... > 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ > 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... > 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ > 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... > 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. > 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ > 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... > 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. > 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ > 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ > 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ > 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ > 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... > 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ > 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ > > 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". > > Thanks, > Neo > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! > >-- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cihula, Joseph
2008-Jul-15 16:33 UTC
RE: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
Espen, For users that do care about the security provided by an IOMMU, especially when used in conjunction with something like Intel(R) Trusted Execution Technology, it is important not to just disable expected protections. In these cases, it is better just to halt or crash Xen. And the thing to keep in mind is that from a security perspective, a buggy BIOS is not the only possible cause for a corrupted ACPI table; malicious bootloader or post-bootlaoder and pre-tboot/Xen code could also corrupt the tables if it could be used to circumvent protections. But I agree that the default case should be to gracefully handle these types of failures. So perhaps allow the ''iommu'' command line option to take a value (e.g. ''2'') that indicates that the user wants the strict (i.e. crash or halt) behavior. This would only be specified by users that really want the added security. Joe -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Espen Skoglund Sent: Monday, July 14, 2008 6:21 AM To: Keir Fraser Cc: Zhao, Yu; xen-devel@lists.xensource.com; Han, Weidong; Neo Jia; Jean Guyader Subject: Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table [Keir Fraser]> On 14/7/08 07:47, "Neo Jia" <neojia@gmail.com> 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@netronome.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Espen Skoglund
2008-Jul-15 17:02 UTC
RE: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
Agreed. Something like an ''iommu=required'' parameter makes sense in some circumstances. eSk -----Original Message----- From: "Cihula, Joseph" <joseph.cihula@intel.com> Subject: RE: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table Date: Tue, 15 Jul 2008 09:33:06 -0700 Espen, For users that do care about the security provided by an IOMMU, especially when used in conjunction with something like Intel(R) Trusted Execution Technology, it is important not to just disable expected protections. In these cases, it is better just to halt or crash Xen. And the thing to keep in mind is that from a security perspective, a buggy BIOS is not the only possible cause for a corrupted ACPI table; malicious bootloader or post-bootlaoder and pre-tboot/Xen code could also corrupt the tables if it could be used to circumvent protections. But I agree that the default case should be to gracefully handle these types of failures. So perhaps allow the ''iommu'' command line option to take a value (e.g. ''2'') that indicates that the user wants the strict (i.e. crash or halt) behavior. This would only be specified by users that really want the added security. Joe -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Espen Skoglund Sent: Monday, July 14, 2008 6:21 AM To: Keir Fraser Cc: Zhao, Yu; xen-devel@lists.xensource.com; Han, Weidong; Neo Jia; Jean Guyader Subject: Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table [Keir Fraser]> On 14/7/08 07:47, "Neo Jia" <neojia@gmail.com> wrote: >> In line: 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00, theRMRR>> reserved memory region starting address is even higher than its limitaddress.>>=20 >> 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=B9m quite tempted to require =8Ciommu=B9 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Neo Jia
2008-Jul-16 01:31 UTC
[Xen-devel] Re: Workaround for the corrupted Intel X48 DMAR table
Randy, I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch. Thanks, Neo (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007ebf1000 (usable) (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) (XEN) 000000007ec76000 - 000000007fdf1000 (usable) (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) (XEN) 000000007fee1000 - 000000007fee6000 (usable) (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) (XEN) 000000007fef2000 - 000000007fef3000 (usable) (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) (XEN) 000000007feff000 - 000000007ff00000 (usable) (XEN) 000000007ff00000 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) System RAM: 2045MB (2094752kB) (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: FACS 7FE9A000, 0040 (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) (XEN) Xen heap: 14MB (14752kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 6:15 APIC version 20 (XEN) Processor #2 6:15 APIC version 20 (XEN) Processor #1 6:15 APIC version 20 (XEN) Processor #3 6:15 APIC version 20 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) RMRR: base address = e0000, end address = effff (XEN) RMRR: base address = 80000000, end address = 7fffffff (XEN) Intel VT-d has been enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2400.150 MHz processor. (XEN) HVM: VMX enabled (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 1/2 eip 8c000 (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 2/1 eip 8c000 (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 3/3 eip 8c000 (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Brought up 4 CPUs (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote:> Neo, > > Can you try attached patch? I guess you are using add-on graphics card, > right? > > Randy (weidong) > > ------------------------------ > *From:* Han, Weidong > *Sent:* 2008年7月14日 16:00 > *To:* 'Neo Jia'; 'xen-devel@lists.xensource.com' > *Cc:* Zhao, Yu; 'Jean Guyader' > *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table > > It should be a BIOS bug. > > Can you post your changes in "acpi_parse_one_rmrr" function and panic > information? > > Randy (Weidong) > > ------------------------------ > *From:* Neo Jia [mailto:neojia@gmail.com] > *Sent:* 2008年7月14日 14:48 > *To:* xen-devel@lists.xensource.com > *Cc:* Han, Weidong; Zhao, Yu; Jean Guyader > *Subject:* Workaround for the corrupted Intel X48 DMAR table > > hi, > > I am trying the Xen unstable on X48 chipset these days but it failed due to > an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. > > DMAR @ 0x7fef1000 > 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL > 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT > 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... > 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ > 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... > 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ > 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... > 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. > 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ > 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... > 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. > 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ > 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ > 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ > 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ > 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... > 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ > 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ > > 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". > > Thanks, > Neo > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! > >-- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-16 02:14 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
>From your log, one RMRR range is incorrect: (XEN) RMRR: base address = 80000000, end address = 7fffffff.We are setting up environment to debug this issue. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月16日 9:31 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch. Thanks, Neo (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007ebf1000 (usable) (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) (XEN) 000000007ec76000 - 000000007fdf1000 (usable) (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) (XEN) 000000007fee1000 - 000000007fee6000 (usable) (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) (XEN) 000000007fef2000 - 000000007fef3000 (usable) (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) (XEN) 000000007feff000 - 000000007ff00000 (usable) (XEN) 000000007ff00000 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) System RAM: 2045MB (2094752kB) (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: FACS 7FE9A000, 0040 (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) (XEN) Xen heap: 14MB (14752kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 6:15 APIC version 20 (XEN) Processor #2 6:15 APIC version 20 (XEN) Processor #1 6:15 APIC version 20 (XEN) Processor #3 6:15 APIC version 20 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) RMRR: base address = e0000, end address = effff (XEN) RMRR: base address = 80000000, end address = 7fffffff (XEN) Intel VT-d has been enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2400.150 MHz processor. (XEN) HVM: VMX enabled (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 1/2 eip 8c000 (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 2/1 eip 8c000 (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 3/3 eip 8c000 (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Brought up 4 CPUs (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Can you try attached patch? I guess you are using add-on graphics card, right? Randy (weidong) ________________________________ From: Han, Weidong Sent: 2008年7月14日 16:00 To: ''Neo Jia''; ''xen-devel@lists.xensource.com'' Cc: Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-17 09:35 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
Neo, Pls try attached patch, which return error when rmrr range is incorrect during DMAR parsing. This results in disable VT-d. It should let your machine boot successfully. BTW, we are cleaning up VT-d code to handle errors gracefully. Randy (Weidong) ________________________________ From: Han, Weidong Sent: 2008年7月16日 10:14 To: ''Neo Jia'' Cc: ''xen-devel@lists.xensource.com''; Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table>From your log, one RMRR range is incorrect: (XEN) RMRR: base address = 80000000, end address = 7fffffff.We are setting up environment to debug this issue. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月16日 9:31 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch. Thanks, Neo (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007ebf1000 (usable) (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) (XEN) 000000007ec76000 - 000000007fdf1000 (usable) (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) (XEN) 000000007fee1000 - 000000007fee6000 (usable) (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) (XEN) 000000007fef2000 - 000000007fef3000 (usable) (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) (XEN) 000000007feff000 - 000000007ff00000 (usable) (XEN) 000000007ff00000 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) System RAM: 2045MB (2094752kB) (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: FACS 7FE9A000, 0040 (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) (XEN) Xen heap: 14MB (14752kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 6:15 APIC version 20 (XEN) Processor #2 6:15 APIC version 20 (XEN) Processor #1 6:15 APIC version 20 (XEN) Processor #3 6:15 APIC version 20 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) RMRR: base address = e0000, end address = effff (XEN) RMRR: base address = 80000000, end address = 7fffffff (XEN) Intel VT-d has been enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2400.150 MHz processor. (XEN) HVM: VMX enabled (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 1/2 eip 8c000 (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 2/1 eip 8c000 (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 3/3 eip 8c000 (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Brought up 4 CPUs (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Can you try attached patch? I guess you are using add-on graphics card, right? Randy (weidong) ________________________________ From: Han, Weidong Sent: 2008年7月14日 16:00 To: ''Neo Jia''; ''xen-devel@lists.xensource.com'' Cc: Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Neo Jia
2008-Jul-17 09:39 UTC
[Xen-devel] Re: Workaround for the corrupted Intel X48 DMAR table
Randy, Thanks. I do want the VT-d stuffs enabled on that machine. Should I wait for a software workaround for the timeout problem or a new BIOS released from Intel? Thanks, Neo On Thu, Jul 17, 2008 at 2:35 AM, Han, Weidong <weidong.han@intel.com> wrote:> Neo, > > Pls try attached patch, which return error when rmrr range is incorrect > during DMAR parsing. This results in disable VT-d. It should let your > machine boot successfully. BTW, we are cleaning up VT-d code to handle > errors gracefully. > > Randy (Weidong) > > ------------------------------ > *From:* Han, Weidong > *Sent:* 2008年7月16日 10:14 > *To:* 'Neo Jia' > *Cc:* 'xen-devel@lists.xensource.com'; Zhao, Yu; 'Jean Guyader' > *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table > > From your log, one RMRR range is incorrect: (XEN) RMRR: base address > 80000000, end address = 7fffffff. > > We are setting up environment to debug this issue. > > Randy (Weidong) > > ------------------------------ > *From:* Neo Jia [mailto:neojia@gmail.com] > *Sent:* 2008年7月16日 9:31 > *To:* Han, Weidong > *Cc:* xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader > *Subject:* Re: Workaround for the corrupted Intel X48 DMAR table > > Randy, > > I finally can get the serial port PCI card working, though it will hangs > the Dom0 but it is enough for me at this moment. The following is the log > after applying your patch. > > Thanks, > Neo > > (XEN) VGA is graphics mode 1280x1024, 32 bpp > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 1 MBR signatures > (XEN) Found 1 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009dc00 (usable) > (XEN) 000000000009dc00 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 000000007ebf1000 (usable) > (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) > (XEN) 000000007ec76000 - 000000007fdf1000 (usable) > (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) > (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) > (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) > (XEN) 000000007fee1000 - 000000007fee6000 (usable) > (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) > (XEN) 000000007fef2000 - 000000007fef3000 (usable) > (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) > (XEN) 000000007feff000 - 000000007ff00000 (usable) > (XEN) 000000007ff00000 - 0000000080000000 (reserved) > (XEN) 00000000f0000000 - 00000000f8000000 (reserved) > (XEN) 00000000ffe00000 - 0000000100000000 (reserved) > (XEN) System RAM: 2045MB (2094752kB) > (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) > (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) > (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: FACS 7FE9A000, 0040 > (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT > 1000013) > (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) > (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) > (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) > (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) > (XEN) Xen heap: 14MB (14752kB) > (XEN) Domain heap initialised: DMA width 32 bits > (XEN) Processor #0 6:15 APIC version 20 > (XEN) Processor #2 6:15 APIC version 20 > (XEN) Processor #1 6:15 APIC version 20 > (XEN) Processor #3 6:15 APIC version 20 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) RMRR: base address = e0000, end address = effff > (XEN) RMRR: base address = 80000000, end address = 7fffffff > (XEN) Intel VT-d has been enabled > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 2400.150 MHz processor. > (XEN) HVM: VMX enabled > (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b > (XEN) Booting processor 1/2 eip 8c000 > (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b > (XEN) Booting processor 2/1 eip 8c000 > (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b > (XEN) Booting processor 3/3 eip 8c000 > (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b > (XEN) Total of 4 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using new ACK method > (XEN) Platform timer is 3.579MHz ACPI PM Timer > (XEN) Brought up 4 CPUs > (XEN) I/O virtualisation enabled > (XEN) I/O virtualisation for PV guests disabled > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please > disable IOMMU > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > > > On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> > wrote: > >> Neo, >> >> Can you try attached patch? I guess you are using add-on graphics card, >> right? >> >> Randy (weidong) >> >> ------------------------------ >> *From:* Han, Weidong >> *Sent:* 2008年7月14日 16:00 >> *To:* 'Neo Jia'; 'xen-devel@lists.xensource.com' >> *Cc:* Zhao, Yu; 'Jean Guyader' >> *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table >> >> It should be a BIOS bug. >> >> Can you post your changes in "acpi_parse_one_rmrr" function and panic >> information? >> >> Randy (Weidong) >> >> ------------------------------ >> *From:* Neo Jia [mailto:neojia@gmail.com] >> *Sent:* 2008年7月14日 14:48 >> *To:* xen-devel@lists.xensource.com >> *Cc:* Han, Weidong; Zhao, Yu; Jean Guyader >> *Subject:* Workaround for the corrupted Intel X48 DMAR table >> >> hi, >> >> I am trying the Xen unstable on X48 chipset these days but it failed due >> to an corrupted RMRR table in the ACPI. The following is the acpi dump of >> DMAR. >> >> DMAR @ 0x7fef1000 >> 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL >> 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT >> 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... >> 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ >> 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... >> 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ >> 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... >> 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. >> 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ >> 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... >> 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. >> 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ >> 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ >> 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ >> 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ >> 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... >> 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ >> 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ >> >> 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". >> >> Thanks, >> Neo >> -- >> I would remember that if researchers were not ambitious >> probably today we haven't the technology we are using! >> >> > > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! >-- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-18 01:00 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
I don''t think there is a software workaround for timeout problem. You need to wait for a new BIOS. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月17日 17:39 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader; Yang, Xiaowei Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, Thanks. I do want the VT-d stuffs enabled on that machine. Should I wait for a software workaround for the timeout problem or a new BIOS released from Intel? Thanks, Neo On Thu, Jul 17, 2008 at 2:35 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Pls try attached patch, which return error when rmrr range is incorrect during DMAR parsing. This results in disable VT-d. It should let your machine boot successfully. BTW, we are cleaning up VT-d code to handle errors gracefully. Randy (Weidong) ________________________________ From: Han, Weidong Sent: 2008年7月16日 10:14 To: ''Neo Jia'' Cc: ''xen-devel@lists.xensource.com''; Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table From your log, one RMRR range is incorrect: (XEN) RMRR: base address = 80000000, end address = 7fffffff. We are setting up environment to debug this issue. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月16日 9:31 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch. Thanks, Neo (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007ebf1000 (usable) (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) (XEN) 000000007ec76000 - 000000007fdf1000 (usable) (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) (XEN) 000000007fee1000 - 000000007fee6000 (usable) (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) (XEN) 000000007fef2000 - 000000007fef3000 (usable) (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) (XEN) 000000007feff000 - 000000007ff00000 (usable) (XEN) 000000007ff00000 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) System RAM: 2045MB (2094752kB) (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: FACS 7FE9A000, 0040 (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) (XEN) Xen heap: 14MB (14752kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 6:15 APIC version 20 (XEN) Processor #2 6:15 APIC version 20 (XEN) Processor #1 6:15 APIC version 20 (XEN) Processor #3 6:15 APIC version 20 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) RMRR: base address = e0000, end address = effff (XEN) RMRR: base address = 80000000, end address = 7fffffff (XEN) Intel VT-d has been enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2400.150 MHz processor. (XEN) HVM: VMX enabled (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 1/2 eip 8c000 (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 2/1 eip 8c000 (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 3/3 eip 8c000 (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Brought up 4 CPUs (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Can you try attached patch? I guess you are using add-on graphics card, right? Randy (weidong) ________________________________ From: Han, Weidong Sent: 2008年7月14日 16:00 To: ''Neo Jia''; ''xen-devel@lists.xensource.com'' Cc: Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Neo Jia
2008-Jul-18 02:01 UTC
[Xen-devel] Re: Workaround for the corrupted Intel X48 DMAR table
So, the timeout issue is caused by the incorrect BIOS also? Thanks, Neo On Thu, Jul 17, 2008 at 6:00 PM, Han, Weidong <weidong.han@intel.com> wrote:> I don't think there is a software workaround for timeout problem. You > need to wait for a new BIOS. > > Randy (Weidong) > > ------------------------------ > *From:* Neo Jia [mailto:neojia@gmail.com] > *Sent:* 2008年7月17日 17:39 > *To:* Han, Weidong > *Cc:* xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader; Yang, Xiaowei > > *Subject:* Re: Workaround for the corrupted Intel X48 DMAR table > > Randy, > > Thanks. I do want the VT-d stuffs enabled on that machine. > > Should I wait for a software workaround for the timeout problem or a new > BIOS released from Intel? > > Thanks, > Neo > > On Thu, Jul 17, 2008 at 2:35 AM, Han, Weidong <weidong.han@intel.com> > wrote: > >> Neo, >> >> Pls try attached patch, which return error when rmrr range is incorrect >> during DMAR parsing. This results in disable VT-d. It should let your >> machine boot successfully. BTW, we are cleaning up VT-d code to handle >> errors gracefully. >> >> Randy (Weidong) >> >> ------------------------------ >> *From:* Han, Weidong >> *Sent:* 2008年7月16日 10:14 >> *To:* 'Neo Jia' >> *Cc:* 'xen-devel@lists.xensource.com'; Zhao, Yu; 'Jean Guyader' >> *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table >> >> From your log, one RMRR range is incorrect: (XEN) RMRR: base address >> 80000000, end address = 7fffffff. >> >> We are setting up environment to debug this issue. >> >> Randy (Weidong) >> >> ------------------------------ >> *From:* Neo Jia [mailto:neojia@gmail.com] >> *Sent:* 2008年7月16日 9:31 >> *To:* Han, Weidong >> *Cc:* xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader >> *Subject:* Re: Workaround for the corrupted Intel X48 DMAR table >> >> Randy, >> >> I finally can get the serial port PCI card working, though it will hangs >> the Dom0 but it is enough for me at this moment. The following is the log >> after applying your patch. >> >> Thanks, >> Neo >> >> (XEN) VGA is graphics mode 1280x1024, 32 bpp >> (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds >> (XEN) EDID info not retrieved because no DDC retrieval method detected >> (XEN) Disc information: >> (XEN) Found 1 MBR signatures >> (XEN) Found 1 EDD information structures >> (XEN) Xen-e820 RAM map: >> (XEN) 0000000000000000 - 000000000009dc00 (usable) >> (XEN) 000000000009dc00 - 00000000000a0000 (reserved) >> (XEN) 00000000000e0000 - 0000000000100000 (reserved) >> (XEN) 0000000000100000 - 000000007ebf1000 (usable) >> (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) >> (XEN) 000000007ec76000 - 000000007fdf1000 (usable) >> (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) >> (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) >> (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) >> (XEN) 000000007fee1000 - 000000007fee6000 (usable) >> (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) >> (XEN) 000000007fef2000 - 000000007fef3000 (usable) >> (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) >> (XEN) 000000007feff000 - 000000007ff00000 (usable) >> (XEN) 000000007ff00000 - 0000000080000000 (reserved) >> (XEN) 00000000f0000000 - 00000000f8000000 (reserved) >> (XEN) 00000000ffe00000 - 0000000100000000 (reserved) >> (XEN) System RAM: 2045MB (2094752kB) >> (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) >> (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 >> 1000013) >> (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: FACS 7FE9A000, 0040 >> (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT >> 1000013) >> (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT >> 1000013) >> (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT >> 1000013) >> (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT >> 1000013) >> (XEN) Xen heap: 14MB (14752kB) >> (XEN) Domain heap initialised: DMA width 32 bits >> (XEN) Processor #0 6:15 APIC version 20 >> (XEN) Processor #2 6:15 APIC version 20 >> (XEN) Processor #1 6:15 APIC version 20 >> (XEN) Processor #3 6:15 APIC version 20 >> (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 >> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs >> (XEN) RMRR: base address = e0000, end address = effff >> (XEN) RMRR: base address = 80000000, end address = 7fffffff >> (XEN) Intel VT-d has been enabled >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) Detected 2400.150 MHz processor. >> (XEN) HVM: VMX enabled >> (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b >> (XEN) Booting processor 1/2 eip 8c000 >> (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b >> (XEN) Booting processor 2/1 eip 8c000 >> (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b >> (XEN) Booting processor 3/3 eip 8c000 >> (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b >> (XEN) Total of 4 processors activated. >> (XEN) ENABLING IO-APIC IRQs >> (XEN) -> Using new ACK method >> (XEN) Platform timer is 3.579MHz ACPI PM Timer >> (XEN) Brought up 4 CPUs >> (XEN) I/O virtualisation enabled >> (XEN) I/O virtualisation for PV guests disabled >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, >> please disable IOMMU >> (XEN) **************************************** >> (XEN) >> (XEN) Reboot in five seconds... >> >> >> On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> >> wrote: >> >>> Neo, >>> >>> Can you try attached patch? I guess you are using add-on graphics card, >>> right? >>> >>> Randy (weidong) >>> >>> ------------------------------ >>> *From:* Han, Weidong >>> *Sent:* 2008年7月14日 16:00 >>> *To:* 'Neo Jia'; 'xen-devel@lists.xensource.com' >>> *Cc:* Zhao, Yu; 'Jean Guyader' >>> *Subject:* RE: Workaround for the corrupted Intel X48 DMAR table >>> >>> It should be a BIOS bug. >>> >>> Can you post your changes in "acpi_parse_one_rmrr" function and panic >>> information? >>> >>> Randy (Weidong) >>> >>> ------------------------------ >>> *From:* Neo Jia [mailto:neojia@gmail.com] >>> *Sent:* 2008年7月14日 14:48 >>> *To:* xen-devel@lists.xensource.com >>> *Cc:* Han, Weidong; Zhao, Yu; Jean Guyader >>> *Subject:* Workaround for the corrupted Intel X48 DMAR table >>> >>> hi, >>> >>> I am trying the Xen unstable on X48 chipset these days but it failed due >>> to an corrupted RMRR table in the ACPI. The following is the acpi dump of >>> DMAR. >>> >>> DMAR @ 0x7fef1000 >>> 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL >>> 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT >>> 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... >>> 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ >>> 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... >>> 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ >>> 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... >>> 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. >>> 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ >>> 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... >>> 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. >>> 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ >>> 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ >>> 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ >>> 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ >>> 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... >>> 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ >>> 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ >>> >>> 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". >>> >>> Thanks, >>> Neo >>> -- >>> I would remember that if researchers were not ambitious >>> probably today we haven't the technology we are using! >>> >>> >> >> >> -- >> I would remember that if researchers were not ambitious >> probably today we haven't the technology we are using! >> > > > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! >-- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Jul-18 02:05 UTC
[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
Per our investigation, it''s very possible. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月18日 10:02 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader; Yang, Xiaowei Subject: Re: Workaround for the corrupted Intel X48 DMAR table So, the timeout issue is caused by the incorrect BIOS also? Thanks, Neo On Thu, Jul 17, 2008 at 6:00 PM, Han, Weidong <weidong.han@intel.com> wrote: I don''t think there is a software workaround for timeout problem. You need to wait for a new BIOS. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月17日 17:39 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader; Yang, Xiaowei Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, Thanks. I do want the VT-d stuffs enabled on that machine. Should I wait for a software workaround for the timeout problem or a new BIOS released from Intel? Thanks, Neo On Thu, Jul 17, 2008 at 2:35 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Pls try attached patch, which return error when rmrr range is incorrect during DMAR parsing. This results in disable VT-d. It should let your machine boot successfully. BTW, we are cleaning up VT-d code to handle errors gracefully. Randy (Weidong) ________________________________ From: Han, Weidong Sent: 2008年7月16日 10:14 To: ''Neo Jia'' Cc: ''xen-devel@lists.xensource.com''; Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table From your log, one RMRR range is incorrect: (XEN) RMRR: base address = 80000000, end address = 7fffffff. We are setting up environment to debug this issue. Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月16日 9:31 To: Han, Weidong Cc: xen-devel@lists.xensource.com; Zhao, Yu; Jean Guyader Subject: Re: Workaround for the corrupted Intel X48 DMAR table Randy, I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch. Thanks, Neo (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007ebf1000 (usable) (XEN) 000000007ebf1000 - 000000007ec76000 (ACPI NVS) (XEN) 000000007ec76000 - 000000007fdf1000 (usable) (XEN) 000000007fdf1000 - 000000007fdf3000 (reserved) (XEN) 000000007fdf3000 - 000000007fe8b000 (usable) (XEN) 000000007fe8b000 - 000000007fee1000 (ACPI NVS) (XEN) 000000007fee1000 - 000000007fee6000 (usable) (XEN) 000000007fee6000 - 000000007fef2000 (ACPI data) (XEN) 000000007fef2000 - 000000007fef3000 (usable) (XEN) 000000007fef3000 - 000000007feff000 (ACPI data) (XEN) 000000007feff000 - 000000007ff00000 (usable) (XEN) 000000007ff00000 - 0000000080000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) System RAM: 2045MB (2094752kB) (XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL ) (XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL DX48BT2 612 1000013) (XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: FACS 7FE9A000, 0040 (XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL CpuPm 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL Cpu0Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL Cpu1Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL Cpu2Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL Cpu3Ist 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL Cpu0Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL Cpu1Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL Cpu2Cst 612 MSFT 1000013) (XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL Cpu3Cst 612 MSFT 1000013) (XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL DX48BT2 612 MSFT 1000013) (XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL PerfTune 612 MSFT 1000013) (XEN) Xen heap: 14MB (14752kB) (XEN) Domain heap initialised: DMA width 32 bits (XEN) Processor #0 6:15 APIC version 20 (XEN) Processor #2 6:15 APIC version 20 (XEN) Processor #1 6:15 APIC version 20 (XEN) Processor #3 6:15 APIC version 20 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) RMRR: base address = e0000, end address = effff (XEN) RMRR: base address = 80000000, end address = 7fffffff (XEN) Intel VT-d has been enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2400.150 MHz processor. (XEN) HVM: VMX enabled (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 1/2 eip 8c000 (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 2/1 eip 8c000 (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Booting processor 3/3 eip 8c000 (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping 0b (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 3.579MHz ACPI PM Timer (XEN) Brought up 4 CPUs (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@intel.com> wrote: Neo, Can you try attached patch? I guess you are using add-on graphics card, right? Randy (weidong) ________________________________ From: Han, Weidong Sent: 2008年7月14日 16:00 To: ''Neo Jia''; ''xen-devel@lists.xensource.com'' Cc: Zhao, Yu; ''Jean Guyader'' Subject: RE: Workaround for the corrupted Intel X48 DMAR table It should be a BIOS bug. Can you post your changes in "acpi_parse_one_rmrr" function and panic information? Randy (Weidong) ________________________________ From: Neo Jia [mailto:neojia@gmail.com] Sent: 2008年7月14日 14:48 To: xen-devel@lists.xensource.com Cc: Han, Weidong; Zhao, Yu; Jean Guyader Subject: Workaround for the corrupted Intel X48 DMAR table hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00 ................ 0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00 .......... ..... 0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00 ................ 0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00 ..........(..... 0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00 . .............. 0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03 ................ 0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00 .........0...... 00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00 ..X............. 00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00 ..........(..... 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00 ................ 0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01 ................ 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". Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel