Hi,
on a Nehalem system with VT-d enabled we are seeing strange ACPI-Table
contents, especially a corrupted DMAR entry.
The hypervisor shows following data on boot:
(XEN) ACPI: RSDP 000F80E0, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7C469E, 00D4 (r1 PTLTD XSDT 60000 LTP 0)
(XEN) ACPI: FACP BF7C9CC9, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240)
(XEN) ACPI: DSDT BF7C4772, 54D3 (r1 FSC D2619 60000 MSFT 3000001)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: TCPA BF7C9DBD, 0032 (r1 Phoeni x 60000 TL 0)
(XEN) ACPI: SLIT BF7C9DEF, 0030 (r1 FSC 60000 5A)
(XEN) ACPI: EINJ BF7C9E1F, 01B0 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: HEST BF7C9FCF, 0268 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: BERT BF7CA237, 0030 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA267, 00E1 (r1 wheaos wheaosc 60000 INTL 20050624)
(XEN) ACPI: ERST BF7CA348, 0270 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA5B8, 009E (r1 FSC CST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA656, 009E (r1 FSC CST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA6F4, 009E (r1 FSC CST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA792, 009E (r1 FSC CST_PR06 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA830, 015B (r1 FSC PST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA98B, 015B (r1 FSC PST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAAE6, 015B (r1 FSC PST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAC41, 015B (r1 FSC PST_PR06 60000 CSF 1)
(XEN) ACPI: SPCR BF7CAD9C, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
(XEN) ACPI: DMAR BF7CADEC, 00E8 (r1 Intel OEMDMAR 60000 LOHR 1)
(XEN) ACPI: MCFG BF7CAED4, 003C (r1 PTLTD MCFG 60000 LTP 0)
(XEN) ACPI: HPET BF7CAF10, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
(XEN) ACPI: APIC BF7CAF48, 0090 (r1 PTLTD APIC 60000 LTP 0)
(XEN) ACPI: BOOT BF7CAFD8, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
The dom0 kernel prints the following:
[ 8.193909] ACPI: RSDP 00000000000f80e0 00024 (v02 PTLTD )
[ 8.193921] ACPI: XSDT 00000000bf7c469e 000D4 (v01 PTLTD ? XSDT 00060000
LTP 00000000)
[ 8.193929] ACPI: FACP 00000000bf7c9cc9 000F4 (v03 FSC TYLERBRG 00060000
PTL 000F4240)
[ 8.193937] ACPI: DSDT 00000000bf7c4772 054D3 (v01 FSC D2619 00060000
MSFT 03000001)
[ 8.193941] ACPI: FACS 00000000bf7cbfc0 00040
[ 8.193945] ACPI: TCPA 00000000bf7c9dbd 00032 (v01 Phoeni x 00060000
TL 00000000)
[ 8.193950] ACPI: SLIT 00000000bf7c9def 00030 (v01 FSC 00060000
0000005A)
[ 8.193955] ACPI: EINJ 00000000bf7c9e1f 001B0 (v01 PTL WHEAPTL 00060000
PTL 00000001)
[ 8.193960] ACPI: HEST 00000000bf7c9fcf 00268 (v01 PTL WHEAPTL 00060000
PTL 00000001)
[ 8.193964] ACPI: BERT 00000000bf7ca237 00030 (v01 PTL WHEAPTL 00060000
PTL 00000001)
[ 8.193969] ACPI: SSDT 00000000bf7ca267 000E1 (v01 wheaos wheaosc 00060000
INTL 20050624)
[ 8.193974] ACPI: ERST 00000000bf7ca348 00270 (v01 PTL WHEAPTL 00060000
PTL 00000001)
[ 8.193979] ACPI: SSDT 00000000bf7ca5b8 0009E (v01 FSC CST_PR00 00060000
CSF 00000001)
[ 8.193983] ACPI: SSDT 00000000bf7ca656 0009E (v01 FSC CST_PR02 00060000
CSF 00000001)
[ 8.193988] ACPI: SSDT 00000000bf7ca6f4 0009E (v01 FSC CST_PR04 00060000
CSF 00000001)
[ 8.193993] ACPI: SSDT 00000000bf7ca792 0009E (v01 FSC CST_PR06 00060000
CSF 00000001)
[ 8.193997] ACPI: SSDT 00000000bf7ca830 0015B (v01 FSC PST_PR00 00060000
CSF 00000001)
[ 8.194002] ACPI: SSDT 00000000bf7ca98b 0015B (v01 FSC PST_PR02 00060000
CSF 00000001)
[ 8.194007] ACPI: SSDT 00000000bf7caae6 0015B (v01 FSC PST_PR04 00060000
CSF 00000001)
[ 8.194011] ACPI: SSDT 00000000bf7cac41 0015B (v01 FSC PST_PR06 00060000
CSF 00000001)
[ 8.194016] ACPI: SPCR 00000000bf7cad9c 00050 (v01 PTLTD $UCRTBL$ 00060000
PTL 00000001)
[ 8.194021] ACPI: 00000000bf7cadec 000E8 (v01 Intel OEMDMAR 00060000
LOHR 00000001)
[ 8.194025] ACPI: MCFG 00000000bf7caed4 0003C (v01 PTLTD MCFG 00060000
LTP 00000000)
[ 8.194030] ACPI: HPET 00000000bf7caf10 00038 (v01 PTLTD HPETTBL 00060000
LTP 00000001)
[ 8.194035] ACPI: APIC 00000000bf7caf48 00090 (v01 PTLTD ? APIC 00060000
LTP 00000000)
[ 8.194039] ACPI: BOOT 00000000bf7cafd8 00028 (v01 PTLTD $SBFTBL$ 00060000
LTP 00000001)
As you can see, the DMAR eye-catcher is replaced by blanks!
This leads to a programmed panic in the crash kernel later in case of a
panic in dom0...
Any ideas?
BTW: seen in unstable AND 4.0
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28 Internet: ts.fujitsu.com
D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 28/07/2010 10:38, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:> As you can see, the DMAR eye-catcher is replaced by blanks! > This leads to a programmed panic in the crash kernel later in case of a > panic in dom0... > > Any ideas? > BTW: seen in unstable AND 4.0Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* *unconditionally* trashes the DMAR so that dom0 will not parse it. Presumably bad stuff would happen if it did. See for example xen-unstable:20181 changeset comment for something of an explanation and the patch originator. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/28/2010 12:03 PM, Keir Fraser wrote:> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: > >> As you can see, the DMAR eye-catcher is replaced by blanks! >> This leads to a programmed panic in the crash kernel later in case of a >> panic in dom0... >> >> Any ideas? >> BTW: seen in unstable AND 4.0 > > Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* > *unconditionally* trashes the DMAR so that dom0 will not parse it. > Presumably bad stuff would happen if it did.As Dom0 is a pv-kernel, it should be able to ignore this entry. The crash kernel OTOH should not panic due to the trashed entry! What is the correct solution here? The crash kernel expects a valid DMAR entry, as following code in enable_IR_x2apic() suggests: /* IR is required if there is APIC ID > 255 even when running * under KVM */ if (max_physical_apicid > 255 || !kvm_para_available()) { if (max_physical_apicid > 255) { pr_warning("NTR enable_IR_x2apic max_physical_apicid > 255\n"); } if (!kvm_para_available()) { pr_warning("NTR enable_IR_x2apic !kvm_para_available()\n"); } goto nox2apic; } (kernel is 2.6.32.12 from Novell SLES11 SP1, the pr_warnings were added to find the error path - it was the !kvm_para_available()) Looking closer to the code rises some doubts about correctness. The comment at top seems not to be reflected by the following if... Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/07/2010 12:26, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:> On 07/28/2010 12:03 PM, Keir Fraser wrote: >> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >> >>> As you can see, the DMAR eye-catcher is replaced by blanks! >>> This leads to a programmed panic in the crash kernel later in case of a >>> panic in dom0... >>> >>> Any ideas? >>> BTW: seen in unstable AND 4.0 >> >> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >> *unconditionally* trashes the DMAR so that dom0 will not parse it. >> Presumably bad stuff would happen if it did. > > As Dom0 is a pv-kernel, it should be able to ignore this entry. > The crash kernel OTOH should not panic due to the trashed entry! > What is the correct solution here?Could provide a cmdline option to not nobble the DMAR?> The crash kernel expects a valid DMAR entry, as following code in > enable_IR_x2apic() suggests:I don''t know what that function does, nor how the error path below depends on DMAR. DMAR isn''t mentioned in the below code. K.> /* IR is required if there is APIC ID > 255 even when running > * under KVM > */ > if (max_physical_apicid > 255 || !kvm_para_available()) { > if (max_physical_apicid > 255) { > pr_warning("NTR enable_IR_x2apic max_physical_apicid > > 255\n"); > } > if (!kvm_para_available()) { > pr_warning("NTR enable_IR_x2apic !kvm_para_available()\n"); > } > goto nox2apic; > } > > (kernel is 2.6.32.12 from Novell SLES11 SP1, the pr_warnings were added to > find the error path - it was the !kvm_para_available()) > > Looking closer to the code rises some doubts about correctness. The comment > at top seems not to be reflected by the following if... > > > Juergen_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/28/2010 01:39 PM, Keir Fraser wrote:> > > > On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: > >> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >>> >>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>> This leads to a programmed panic in the crash kernel later in case of a >>>> panic in dom0... >>>> >>>> Any ideas? >>>> BTW: seen in unstable AND 4.0 >>> >>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>> Presumably bad stuff would happen if it did. >> >> As Dom0 is a pv-kernel, it should be able to ignore this entry. >> The crash kernel OTOH should not panic due to the trashed entry! >> What is the correct solution here? > > Could provide a cmdline option to not nobble the DMAR?That''s a possibility. I wonder whether it wouldn''t be better to let dom0 decide not to use it if running under xen. This would remove the requirement for zapping the ACPI table. IMO it''s always a bad idea to change data of a deeper layer...> >> The crash kernel expects a valid DMAR entry, as following code in >> enable_IR_x2apic() suggests: > > I don''t know what that function does, nor how the error path below depends > on DMAR. DMAR isn''t mentioned in the below code.Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): void __init enable_IR_x2apic(void) { unsigned long flags; struct IO_APIC_route_entry **ioapic_entries = NULL; int ret, x2apic_enabled = 0; int dmar_table_init_ret = 0; #ifdef CONFIG_INTR_REMAP dmar_table_init_ret = dmar_table_init(); if (dmar_table_init_ret) pr_debug("dmar_table_init() failed with %d:\n", dmar_table_init_ret); #endif ioapic_entries = alloc_ioapic_entries(); if (!ioapic_entries) { pr_err("Allocate ioapic_entries failed\n"); goto out; } ret = save_IO_APIC_setup(ioapic_entries); if (ret) { pr_info("Saving IO-APIC state failed: %d\n", ret); goto out; } local_irq_save(flags); mask_8259A(); mask_IO_APIC_setup(ioapic_entries); if (dmar_table_init_ret) ret = 0; else ret = enable_IR(); if (!ret) { /* IR is required if there is APIC ID > 255 even when running * under KVM */ if (max_physical_apicid > 255 || !kvm_para_available()) goto nox2apic; /* * without IR all CPUs can be addressed by IOAPIC/MSI * only in physical mode */ x2apic_force_phys(); } x2apic_enabled = 1; if (x2apic_supported() && !x2apic_mode) { x2apic_mode = 1; enable_x2apic(); pr_info("Enabled x2apic\n"); } nox2apic: if (!ret) /* IR enabling failed */ restore_IO_APIC_setup(ioapic_entries); unmask_8259A(); local_irq_restore(flags); out: if (ioapic_entries) free_ioapic_entries(ioapic_entries); if (x2apic_enabled) return; if (x2apic_preenabled) panic("x2apic: enabled by BIOS but kernel init failed."); else if (cpu_has_x2apic) pr_info("Not enabling x2apic, Intr-remapping init failed.\n"); } dmar_table_init() will return -ENODEV if no DMAR record is found. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/07/2010 13:13, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>> The crash kernel OTOH should not panic due to the trashed entry! >>> What is the correct solution here? >> >> Could provide a cmdline option to not nobble the DMAR? > > That''s a possibility. > I wonder whether it wouldn''t be better to let dom0 decide not to use it if > running under xen. This would remove the requirement for zapping the ACPI > table. IMO it''s always a bad idea to change data of a deeper layer...If we don''t zap the DMAR then every existing dom0 kernel will fail with new hypervisor. We could gate it on a new elfnote, or rename to XMAR and have dom0 rename it back, or just have a flag day.>>> The crash kernel expects a valid DMAR entry, as following code in >>> enable_IR_x2apic() suggests: >> >> I don''t know what that function does, nor how the error path below depends >> on DMAR. DMAR isn''t mentioned in the below code. > > Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): > /* IR is required if there is APIC ID > 255 even when running > * under KVM > */ > if (max_physical_apicid > 255 || !kvm_para_available()) > goto nox2apic;The if stmt is confusing. Also, what would happen if this kernel was booted on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a DMAR-less environment -- there must be something odd going on for it to end on this path for us. -- Keir> /* > * without IR all CPUs can be addressed by IOAPIC/MSI > * only in physical mode > */ > x2apic_force_phys(); > } > > x2apic_enabled = 1; > > if (x2apic_supported() && !x2apic_mode) { > x2apic_mode = 1; > enable_x2apic(); > pr_info("Enabled x2apic\n"); > } > > nox2apic: > if (!ret) /* IR enabling failed */ > restore_IO_APIC_setup(ioapic_entries); > unmask_8259A(); > local_irq_restore(flags); > > out: > if (ioapic_entries) > free_ioapic_entries(ioapic_entries); > > if (x2apic_enabled) > return; > > if (x2apic_preenabled) > panic("x2apic: enabled by BIOS but kernel init failed."); > else if (cpu_has_x2apic) > pr_info("Not enabling x2apic, Intr-remapping init > failed.\n"); > } > > > dmar_table_init() will return -ENODEV if no DMAR record is found. > > > Juergen_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/28/2010 02:45 PM, Keir Fraser wrote:> On 28/07/2010 13:13, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: > >>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>> The crash kernel OTOH should not panic due to the trashed entry! >>>> What is the correct solution here? >>> >>> Could provide a cmdline option to not nobble the DMAR? >> >> That''s a possibility. >> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >> running under xen. This would remove the requirement for zapping the ACPI >> table. IMO it''s always a bad idea to change data of a deeper layer... > > If we don''t zap the DMAR then every existing dom0 kernel will fail with new > hypervisor. We could gate it on a new elfnote, or rename to XMAR and have > dom0 rename it back, or just have a flag day.The really clean solution would be to virtualize the ACPI table for dom0 and remove the DMAR entry in this version. This would require some major work, I guess (clone at least the BIOS page containing the ACPI anchor and present a modified version to dom0).> >>>> The crash kernel expects a valid DMAR entry, as following code in >>>> enable_IR_x2apic() suggests: >>> >>> I don''t know what that function does, nor how the error path below depends >>> on DMAR. DMAR isn''t mentioned in the below code. >> >> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >> /* IR is required if there is APIC ID> 255 even when running >> * under KVM >> */ >> if (max_physical_apicid> 255 || !kvm_para_available()) >> goto nox2apic; > > The if stmt is confusing. Also, what would happen if this kernel was booted > on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a > DMAR-less environment -- there must be something odd going on for it to end > on this path for us.Yeah, that puzzled me, too. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The really clean solution would be to virtualize the ACPI table for dom0 and > remove the DMAR entry in this version. This would require some major work, I > guess (clone at least the BIOS page containing the ACPI anchor and present > a modified version to dom0).Well, that is what it does right now. It zeros it out so that the DMAR entry is gone from the ACPI tables. I am not really sure that having a DMAR accessible to Dom0 is good. You would have two entities trying to write to the DMAR''s to control the IOMMU and the PCI devices. Does Xen enable the IOMMU? Do you see that in the serial log?> > > > >>>>The crash kernel expects a valid DMAR entry, as following code in > >>>>enable_IR_x2apic() suggests: > >>> > >>>I don''t know what that function does, nor how the error path below depends > >>>on DMAR. DMAR isn''t mentioned in the below code. > >> > >>Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): > >> /* IR is required if there is APIC ID> 255 even when running > >> * under KVM > >> */ > >> if (max_physical_apicid> 255 || !kvm_para_available()) > >> goto nox2apic; > > > >The if stmt is confusing. Also, what would happen if this kernel was booted > >on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a > >DMAR-less environment -- there must be something odd going on for it to end > >on this path for us. > > Yeah, that puzzled me, too.What is the crash? And do you see any indiciation that x2APIC is turned on? Do provide a serial log please. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/28/2010 03:36 PM, Konrad Rzeszutek Wilk wrote:>> The really clean solution would be to virtualize the ACPI table for dom0 and >> remove the DMAR entry in this version. This would require some major work, I >> guess (clone at least the BIOS page containing the ACPI anchor and present >> a modified version to dom0). > > Well, that is what it does right now. It zeros it out so that the DMAR > entry is gone from the ACPI tables.No. It changes the ORIGINAL ACPI table, not a copy of it.> > I am not really sure that having a DMAR accessible to Dom0 is good. You > would have two entities trying to write to the DMAR''s to control the > IOMMU and the PCI devices. Does Xen enable the IOMMU? Do you see that in > the serial log?I don''t want to let dom0 access DMAR. I want the crash kernel be able to access it. And I think Xen does enable the IOMMU: (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Intel machine check reporting enabled (XEN) Intel VT-d Snoop Control supported. (XEN) Intel VT-d DMA Passthrough not supported. (XEN) Intel VT-d Queued Invalidation supported. (XEN) Intel VT-d Interrupt Remapping supported. (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) x2APIC mode enabled.>> >>> >>>>>> The crash kernel expects a valid DMAR entry, as following code in >>>>>> enable_IR_x2apic() suggests: >>>>> >>>>> I don''t know what that function does, nor how the error path below depends >>>>> on DMAR. DMAR isn''t mentioned in the below code. >>>> >>>> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >>>> /* IR is required if there is APIC ID> 255 even when running >>>> * under KVM >>>> */ >>>> if (max_physical_apicid> 255 || !kvm_para_available()) >>>> goto nox2apic; >>> >>> The if stmt is confusing. Also, what would happen if this kernel was booted >>> on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a >>> DMAR-less environment -- there must be something odd going on for it to end >>> on this path for us. >> >> Yeah, that puzzled me, too. > > What is the crash? And do you see any indiciation that x2APIC is turned > on? Do provide a serial log please.Log is attached. I did some more testing. The problem occurred on a Nehalem-EX system. I tried the same on a Nehalem-EP system and all was okay. I suspect some further problems in the ACPI tables of the EX system now. I''m not too familiar with ACPI tables. Anything I can do for further analysis? Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will not
control interrupt controller, either xapic, or x2apic. Shouldn''t this
be commented out in pvops dom0?
What''s the panic point in your environment? Is it the following code?
If yes, that means you enable x2apic in BIOS and you can workaround this issue
by disable x2apic in BIOS.
if (x2apic_preenabled)
panic("x2apic: enabled by BIOS but kernel init
failed.");
Thanks
--jyh
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross
>Sent: Wednesday, July 28, 2010 8:14 PM
>To: Keir Fraser
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] ACPI-Tables corrupted?
>
>On 07/28/2010 01:39 PM, Keir Fraser wrote:
>>
>>
>>
>> On 28/07/2010 12:26, "Juergen
Gross"<juergen.gross@ts.fujitsu.com> wrote:
>>
>>> On 07/28/2010 12:03 PM, Keir Fraser wrote:
>>>> On 28/07/2010 10:38, "Juergen
Gross"<juergen.gross@ts.fujitsu.com>
>wrote:
>>>>
>>>>> As you can see, the DMAR eye-catcher is replaced by blanks!
>>>>> This leads to a programmed panic in the crash kernel later
in case of a
>>>>> panic in dom0...
>>>>>
>>>>> Any ideas?
>>>>> BTW: seen in unstable AND 4.0
>>>>
>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen
*always*
>>>> *unconditionally* trashes the DMAR so that dom0 will not parse
it.
>>>> Presumably bad stuff would happen if it did.
>>>
>>> As Dom0 is a pv-kernel, it should be able to ignore this entry.
>>> The crash kernel OTOH should not panic due to the trashed entry!
>>> What is the correct solution here?
>>
>> Could provide a cmdline option to not nobble the DMAR?
>
>That''s a possibility.
>I wonder whether it wouldn''t be better to let dom0 decide not to
use it if
>running under xen. This would remove the requirement for zapping the ACPI
>table. IMO it''s always a bad idea to change data of a deeper
layer...
>
>>
>>> The crash kernel expects a valid DMAR entry, as following code in
>>> enable_IR_x2apic() suggests:
>>
>> I don''t know what that function does, nor how the error path
below depends
>> on DMAR. DMAR isn''t mentioned in the below code.
>
>Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c):
>
>void __init enable_IR_x2apic(void)
>{
> unsigned long flags;
> struct IO_APIC_route_entry **ioapic_entries = NULL;
> int ret, x2apic_enabled = 0;
> int dmar_table_init_ret = 0;
>
>#ifdef CONFIG_INTR_REMAP
> dmar_table_init_ret = dmar_table_init();
> if (dmar_table_init_ret)
> pr_debug("dmar_table_init() failed with %d:\n",
> dmar_table_init_ret);
>#endif
>
> ioapic_entries = alloc_ioapic_entries();
> if (!ioapic_entries) {
> pr_err("Allocate ioapic_entries failed\n");
> goto out;
> }
>
> ret = save_IO_APIC_setup(ioapic_entries);
> if (ret) {
> pr_info("Saving IO-APIC state failed: %d\n",
ret);
> goto out;
> }
>
> local_irq_save(flags);
> mask_8259A();
> mask_IO_APIC_setup(ioapic_entries);
>
> if (dmar_table_init_ret)
> ret = 0;
> else
> ret = enable_IR();
>
> if (!ret) {
> /* IR is required if there is APIC ID > 255 even when
running
> * under KVM
> */
> if (max_physical_apicid > 255 || !kvm_para_available())
> goto nox2apic;
> /*
> * without IR all CPUs can be addressed by IOAPIC/MSI
> * only in physical mode
> */
> x2apic_force_phys();
> }
>
> x2apic_enabled = 1;
>
> if (x2apic_supported() && !x2apic_mode) {
> x2apic_mode = 1;
> enable_x2apic();
> pr_info("Enabled x2apic\n");
> }
>
>nox2apic:
> if (!ret) /* IR enabling failed */
> restore_IO_APIC_setup(ioapic_entries);
> unmask_8259A();
> local_irq_restore(flags);
>
>out:
> if (ioapic_entries)
> free_ioapic_entries(ioapic_entries);
>
> if (x2apic_enabled)
> return;
>
> if (x2apic_preenabled)
> panic("x2apic: enabled by BIOS but kernel init
failed.");
> else if (cpu_has_x2apic)
> pr_info("Not enabling x2apic, Intr-remapping init
failed.\n");
>}
>
>
>dmar_table_init() will return -ENODEV if no DMAR record is found.
>
>
>Juergen
>
>--
>Juergen Gross Principal Developer Operating Systems
>TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967
>Fujitsu Technology Solutions e-mail:
juergen.gross@ts.fujitsu.com
>Domagkstr. 28 Internet: ts.fujitsu.com
>D-80807 Muenchen Company details:
>ts.fujitsu.com/imprint.html
>
>_______________________________________________
>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
On 29/07/2010 07:19, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:>> What is the crash? And do you see any indiciation that x2APIC is turned >> on? Do provide a serial log please. > > Log is attached. > > I did some more testing. The problem occurred on a Nehalem-EX system. I tried > the same on a Nehalem-EP system and all was okay. I suspect some further > problems in the ACPI tables of the EX system now. I''m not too familiar with > ACPI tables. Anything I can do for further analysis?Okay I think now that the crash is legitimate. The easy fix is that we should reinstate the DMAR before kexec''ing the crash kernel. I''ll look into doing a patch to the hypervisor later today. Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s not a dom0, it''s a kexec''ed crash kernel. We should be reinstating DMAR before jumping into a native kernel. I will sort out a fix. -- Keir On 29/07/2010 07:31, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will > not control interrupt controller, either xapic, or x2apic. Shouldn''t this be > commented out in pvops dom0? > > What''s the panic point in your environment? Is it the following code? If yes, > that means you enable x2apic in BIOS and you can workaround this issue by > disable x2apic in BIOS. > > if (x2apic_preenabled) > panic("x2apic: enabled by BIOS but kernel init failed."); > > Thanks > --jyh > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >> Sent: Wednesday, July 28, 2010 8:14 PM >> To: Keir Fraser >> Cc: xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >> >> On 07/28/2010 01:39 PM, Keir Fraser wrote: >>> >>> >>> >>> On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >>> >>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >> wrote: >>>>> >>>>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>>>> This leads to a programmed panic in the crash kernel later in case of a >>>>>> panic in dom0... >>>>>> >>>>>> Any ideas? >>>>>> BTW: seen in unstable AND 4.0 >>>>> >>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>>>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>>>> Presumably bad stuff would happen if it did. >>>> >>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>> The crash kernel OTOH should not panic due to the trashed entry! >>>> What is the correct solution here? >>> >>> Could provide a cmdline option to not nobble the DMAR? >> >> That''s a possibility. >> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >> running under xen. This would remove the requirement for zapping the ACPI >> table. IMO it''s always a bad idea to change data of a deeper layer... >> >>> >>>> The crash kernel expects a valid DMAR entry, as following code in >>>> enable_IR_x2apic() suggests: >>> >>> I don''t know what that function does, nor how the error path below depends >>> on DMAR. DMAR isn''t mentioned in the below code. >> >> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >> >> void __init enable_IR_x2apic(void) >> { >> unsigned long flags; >> struct IO_APIC_route_entry **ioapic_entries = NULL; >> int ret, x2apic_enabled = 0; >> int dmar_table_init_ret = 0; >> >> #ifdef CONFIG_INTR_REMAP >> dmar_table_init_ret = dmar_table_init(); >> if (dmar_table_init_ret) >> pr_debug("dmar_table_init() failed with %d:\n", >> dmar_table_init_ret); >> #endif >> >> ioapic_entries = alloc_ioapic_entries(); >> if (!ioapic_entries) { >> pr_err("Allocate ioapic_entries failed\n"); >> goto out; >> } >> >> ret = save_IO_APIC_setup(ioapic_entries); >> if (ret) { >> pr_info("Saving IO-APIC state failed: %d\n", ret); >> goto out; >> } >> >> local_irq_save(flags); >> mask_8259A(); >> mask_IO_APIC_setup(ioapic_entries); >> >> if (dmar_table_init_ret) >> ret = 0; >> else >> ret = enable_IR(); >> >> if (!ret) { >> /* IR is required if there is APIC ID > 255 even when running >> * under KVM >> */ >> if (max_physical_apicid > 255 || !kvm_para_available()) >> goto nox2apic; >> /* >> * without IR all CPUs can be addressed by IOAPIC/MSI >> * only in physical mode >> */ >> x2apic_force_phys(); >> } >> >> x2apic_enabled = 1; >> >> if (x2apic_supported() && !x2apic_mode) { >> x2apic_mode = 1; >> enable_x2apic(); >> pr_info("Enabled x2apic\n"); >> } >> >> nox2apic: >> if (!ret) /* IR enabling failed */ >> restore_IO_APIC_setup(ioapic_entries); >> unmask_8259A(); >> local_irq_restore(flags); >> >> out: >> if (ioapic_entries) >> free_ioapic_entries(ioapic_entries); >> >> if (x2apic_enabled) >> return; >> >> if (x2apic_preenabled) >> panic("x2apic: enabled by BIOS but kernel init failed."); >> else if (cpu_has_x2apic) >> pr_info("Not enabling x2apic, Intr-remapping init >> failed.\n"); >> } >> >> >> dmar_table_init() will return -ENODEV if no DMAR record is found. >> >> >> Juergen >> >> -- >> Juergen Gross Principal Developer Operating Systems >> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 >> Fujitsu Technology Solutions e-mail: >> juergen.gross@ts.fujitsu.com >> Domagkstr. 28 Internet: ts.fujitsu.com >> D-80807 Muenchen Company details: >> ts.fujitsu.com/imprint.html >> >> _______________________________________________ >> 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
On 07/29/2010 08:39 AM, Keir Fraser wrote:> On 29/07/2010 07:19, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: > >>> What is the crash? And do you see any indiciation that x2APIC is turned >>> on? Do provide a serial log please. >> >> Log is attached. >> >> I did some more testing. The problem occurred on a Nehalem-EX system. I tried >> the same on a Nehalem-EP system and all was okay. I suspect some further >> problems in the ACPI tables of the EX system now. I''m not too familiar with >> ACPI tables. Anything I can do for further analysis? > > Okay I think now that the crash is legitimate. The easy fix is that we > should reinstate the DMAR before kexec''ing the crash kernel. I''ll look into > doing a patch to the hypervisor later today.Thanks! BTW: Do you understand why the EP system has no problems with the patched DMAR entry? Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Strictly speaking we should have a stab at disabling x2apic as well, but that''s harder. And not necessary for newer Linux kernels, which is what we will usually be kexec''ing to anyway. -- Keir On 29/07/2010 07:40, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> It''s not a dom0, it''s a kexec''ed crash kernel. We should be reinstating DMAR > before jumping into a native kernel. I will sort out a fix. > > -- Keir > > On 29/07/2010 07:31, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > >> A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will >> not control interrupt controller, either xapic, or x2apic. Shouldn''t this be >> commented out in pvops dom0? >> >> What''s the panic point in your environment? Is it the following code? If yes, >> that means you enable x2apic in BIOS and you can workaround this issue by >> disable x2apic in BIOS. >> >> if (x2apic_preenabled) >> panic("x2apic: enabled by BIOS but kernel init failed."); >> >> Thanks >> --jyh >> >>> -----Original Message----- >>> From: xen-devel-bounces@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >>> Sent: Wednesday, July 28, 2010 8:14 PM >>> To: Keir Fraser >>> Cc: xen-devel@lists.xensource.com >>> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >>> >>> On 07/28/2010 01:39 PM, Keir Fraser wrote: >>>> >>>> >>>> >>>> On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >>>> >>>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >>> wrote: >>>>>> >>>>>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>>>>> This leads to a programmed panic in the crash kernel later in case of a >>>>>>> panic in dom0... >>>>>>> >>>>>>> Any ideas? >>>>>>> BTW: seen in unstable AND 4.0 >>>>>> >>>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>>>>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>>>>> Presumably bad stuff would happen if it did. >>>>> >>>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>>> The crash kernel OTOH should not panic due to the trashed entry! >>>>> What is the correct solution here? >>>> >>>> Could provide a cmdline option to not nobble the DMAR? >>> >>> That''s a possibility. >>> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >>> running under xen. This would remove the requirement for zapping the ACPI >>> table. IMO it''s always a bad idea to change data of a deeper layer... >>> >>>> >>>>> The crash kernel expects a valid DMAR entry, as following code in >>>>> enable_IR_x2apic() suggests: >>>> >>>> I don''t know what that function does, nor how the error path below depends >>>> on DMAR. DMAR isn''t mentioned in the below code. >>> >>> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >>> >>> void __init enable_IR_x2apic(void) >>> { >>> unsigned long flags; >>> struct IO_APIC_route_entry **ioapic_entries = NULL; >>> int ret, x2apic_enabled = 0; >>> int dmar_table_init_ret = 0; >>> >>> #ifdef CONFIG_INTR_REMAP >>> dmar_table_init_ret = dmar_table_init(); >>> if (dmar_table_init_ret) >>> pr_debug("dmar_table_init() failed with %d:\n", >>> dmar_table_init_ret); >>> #endif >>> >>> ioapic_entries = alloc_ioapic_entries(); >>> if (!ioapic_entries) { >>> pr_err("Allocate ioapic_entries failed\n"); >>> goto out; >>> } >>> >>> ret = save_IO_APIC_setup(ioapic_entries); >>> if (ret) { >>> pr_info("Saving IO-APIC state failed: %d\n", ret); >>> goto out; >>> } >>> >>> local_irq_save(flags); >>> mask_8259A(); >>> mask_IO_APIC_setup(ioapic_entries); >>> >>> if (dmar_table_init_ret) >>> ret = 0; >>> else >>> ret = enable_IR(); >>> >>> if (!ret) { >>> /* IR is required if there is APIC ID > 255 even when >>> running >>> * under KVM >>> */ >>> if (max_physical_apicid > 255 || !kvm_para_available()) >>> goto nox2apic; >>> /* >>> * without IR all CPUs can be addressed by IOAPIC/MSI >>> * only in physical mode >>> */ >>> x2apic_force_phys(); >>> } >>> >>> x2apic_enabled = 1; >>> >>> if (x2apic_supported() && !x2apic_mode) { >>> x2apic_mode = 1; >>> enable_x2apic(); >>> pr_info("Enabled x2apic\n"); >>> } >>> >>> nox2apic: >>> if (!ret) /* IR enabling failed */ >>> restore_IO_APIC_setup(ioapic_entries); >>> unmask_8259A(); >>> local_irq_restore(flags); >>> >>> out: >>> if (ioapic_entries) >>> free_ioapic_entries(ioapic_entries); >>> >>> if (x2apic_enabled) >>> return; >>> >>> if (x2apic_preenabled) >>> panic("x2apic: enabled by BIOS but kernel init failed."); >>> else if (cpu_has_x2apic) >>> pr_info("Not enabling x2apic, Intr-remapping init >>> failed.\n"); >>> } >>> >>> >>> dmar_table_init() will return -ENODEV if no DMAR record is found. >>> >>> >>> Juergen >>> >>> -- >>> Juergen Gross Principal Developer Operating Systems >>> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 >>> Fujitsu Technology Solutions e-mail: >>> juergen.gross@ts.fujitsu.com >>> Domagkstr. 28 Internet: ts.fujitsu.com >>> D-80807 Muenchen Company details: >>> ts.fujitsu.com/imprint.html >>> >>> _______________________________________________ >>> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/07/2010 07:48, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:>> Okay I think now that the crash is legitimate. The easy fix is that we >> should reinstate the DMAR before kexec''ing the crash kernel. I''ll look into >> doing a patch to the hypervisor later today. > > Thanks! > BTW: Do you understand why the EP system has no problems with the patched DMAR > entry?It probably doesn''t have x2apic support. Any hint of x2apic in its boot logs? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/29/2010 08:48 AM, Keir Fraser wrote:> On 29/07/2010 07:48, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: > >>> Okay I think now that the crash is legitimate. The easy fix is that we >>> should reinstate the DMAR before kexec''ing the crash kernel. I''ll look into >>> doing a patch to the hypervisor later today. >> >> Thanks! >> BTW: Do you understand why the EP system has no problems with the patched DMAR >> entry? > > It probably doesn''t have x2apic support. Any hint of x2apic in its boot > logs?Ahh, I see. No, it seems not to have x2apic. Thanks, Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sorry that I didn''t notice it is for crash kernel. In fact, I tried kexec before and never succed to bring it up. What do you mean of "stab at disabling x2apic"? You mean we need disable x2apic before transfer control to crash kernel, right? Per my understanding, with kexec, when system crash, it will jump directly to new kernel''s entry point, no guest destroy (i.e. clean-up), not reset signal to cpu/chipset, right? If yes, another issue need be considered is VT-d. I didn''t find the vt-d disable code in xen''s kexec_crash code, if the new kernel has no idea of vt-d (thus does not reset the vt-d engine), it may have trouble. Or, will the kexec kernel not use device assigned to guest? Of course it is ok if crash kernel support vt-d too. Thanks --jyh>-----Original Message----- >From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >Sent: Thursday, July 29, 2010 2:48 PM >To: Jiang, Yunhong; Juergen Gross >Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Han, Weidong >Subject: Re: [Xen-devel] ACPI-Tables corrupted? > >Strictly speaking we should have a stab at disabling x2apic as well, but >that''s harder. And not necessary for newer Linux kernels, which is what we >will usually be kexec''ing to anyway. > > -- Keir > >On 29/07/2010 07:40, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > >> It''s not a dom0, it''s a kexec''ed crash kernel. We should be reinstating DMAR >> before jumping into a native kernel. I will sort out a fix. >> >> -- Keir >> >> On 29/07/2010 07:31, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >> >>> A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will >>> not control interrupt controller, either xapic, or x2apic. Shouldn''t this be >>> commented out in pvops dom0? >>> >>> What''s the panic point in your environment? Is it the following code? If yes, >>> that means you enable x2apic in BIOS and you can workaround this issue by >>> disable x2apic in BIOS. >>> >>> if (x2apic_preenabled) >>> panic("x2apic: enabled by BIOS but kernel init failed."); >>> >>> Thanks >>> --jyh >>> >>>> -----Original Message----- >>>> From: xen-devel-bounces@lists.xensource.com >>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >>>> Sent: Wednesday, July 28, 2010 8:14 PM >>>> To: Keir Fraser >>>> Cc: xen-devel@lists.xensource.com >>>> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >>>> >>>> On 07/28/2010 01:39 PM, Keir Fraser wrote: >>>>> >>>>> >>>>> >>>>> On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >wrote: >>>>> >>>>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >>>> wrote: >>>>>>> >>>>>>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>>>>>> This leads to a programmed panic in the crash kernel later in case of a >>>>>>>> panic in dom0... >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> BTW: seen in unstable AND 4.0 >>>>>>> >>>>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>>>>>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>>>>>> Presumably bad stuff would happen if it did. >>>>>> >>>>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>>>> The crash kernel OTOH should not panic due to the trashed entry! >>>>>> What is the correct solution here? >>>>> >>>>> Could provide a cmdline option to not nobble the DMAR? >>>> >>>> That''s a possibility. >>>> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >>>> running under xen. This would remove the requirement for zapping the ACPI >>>> table. IMO it''s always a bad idea to change data of a deeper layer... >>>> >>>>> >>>>>> The crash kernel expects a valid DMAR entry, as following code in >>>>>> enable_IR_x2apic() suggests: >>>>> >>>>> I don''t know what that function does, nor how the error path below depends >>>>> on DMAR. DMAR isn''t mentioned in the below code. >>>> >>>> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >>>> >>>> void __init enable_IR_x2apic(void) >>>> { >>>> unsigned long flags; >>>> struct IO_APIC_route_entry **ioapic_entries = NULL; >>>> int ret, x2apic_enabled = 0; >>>> int dmar_table_init_ret = 0; >>>> >>>> #ifdef CONFIG_INTR_REMAP >>>> dmar_table_init_ret = dmar_table_init(); >>>> if (dmar_table_init_ret) >>>> pr_debug("dmar_table_init() failed with %d:\n", >>>> dmar_table_init_ret); >>>> #endif >>>> >>>> ioapic_entries = alloc_ioapic_entries(); >>>> if (!ioapic_entries) { >>>> pr_err("Allocate ioapic_entries failed\n"); >>>> goto out; >>>> } >>>> >>>> ret = save_IO_APIC_setup(ioapic_entries); >>>> if (ret) { >>>> pr_info("Saving IO-APIC state failed: %d\n", ret); >>>> goto out; >>>> } >>>> >>>> local_irq_save(flags); >>>> mask_8259A(); >>>> mask_IO_APIC_setup(ioapic_entries); >>>> >>>> if (dmar_table_init_ret) >>>> ret = 0; >>>> else >>>> ret = enable_IR(); >>>> >>>> if (!ret) { >>>> /* IR is required if there is APIC ID > 255 even when >>>> running >>>> * under KVM >>>> */ >>>> if (max_physical_apicid > 255 || !kvm_para_available()) >>>> goto nox2apic; >>>> /* >>>> * without IR all CPUs can be addressed by IOAPIC/MSI >>>> * only in physical mode >>>> */ >>>> x2apic_force_phys(); >>>> } >>>> >>>> x2apic_enabled = 1; >>>> >>>> if (x2apic_supported() && !x2apic_mode) { >>>> x2apic_mode = 1; >>>> enable_x2apic(); >>>> pr_info("Enabled x2apic\n"); >>>> } >>>> >>>> nox2apic: >>>> if (!ret) /* IR enabling failed */ >>>> restore_IO_APIC_setup(ioapic_entries); >>>> unmask_8259A(); >>>> local_irq_restore(flags); >>>> >>>> out: >>>> if (ioapic_entries) >>>> free_ioapic_entries(ioapic_entries); >>>> >>>> if (x2apic_enabled) >>>> return; >>>> >>>> if (x2apic_preenabled) >>>> panic("x2apic: enabled by BIOS but kernel init failed."); >>>> else if (cpu_has_x2apic) >>>> pr_info("Not enabling x2apic, Intr-remapping init >>>> failed.\n"); >>>> } >>>> >>>> >>>> dmar_table_init() will return -ENODEV if no DMAR record is found. >>>> >>>> >>>> Juergen >>>> >>>> -- >>>> Juergen Gross Principal Developer Operating Systems >>>> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 >>>> Fujitsu Technology Solutions e-mail: >>>> juergen.gross@ts.fujitsu.com >>>> Domagkstr. 28 Internet: ts.fujitsu.com >>>> D-80807 Muenchen Company details: >>>> ts.fujitsu.com/imprint.html >>>> >>>> _______________________________________________ >>>> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/29/2010 09:37 AM, Jiang, Yunhong wrote:> Sorry that I didn''t notice it is for crash kernel. In fact, I tried kexec before and never succed to bring it up. > > What do you mean of "stab at disabling x2apic"? You mean we need disable x2apic before transfer control to crash kernel, right? > > Per my understanding, with kexec, when system crash, it will jump directly to new kernel''s entry point, no guest destroy (i.e. clean-up), not reset signal to cpu/chipset, right? > If yes, another issue need be considered is VT-d. I didn''t find the vt-d disable code in xen''s kexec_crash code, if the new kernel has no idea of vt-d (thus does not reset the vt-d engine), it may have trouble. Or, will the kexec kernel not use device assigned to guest? > > Of course it is ok if crash kernel support vt-d too.Seems to be the case here. A patched crash kernel which just took the zapped DMAR entry as a valid one succeeded in writing a vmcore. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/07/2010 08:37, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> Sorry that I didn''t notice it is for crash kernel. In fact, I tried kexec > before and never succed to bring it up. > > What do you mean of "stab at disabling x2apic"? You mean we need disable > x2apic before transfer control to crash kernel, right? > > Per my understanding, with kexec, when system crash, it will jump directly to > new kernel''s entry point, no guest destroy (i.e. clean-up), not reset signal > to cpu/chipset, right? > If yes, another issue need be considered is VT-d. I didn''t find the vt-d > disable code in xen''s kexec_crash code, if the new kernel has no idea of vt-d > (thus does not reset the vt-d engine), it may have trouble. Or, will the kexec > kernel not use device assigned to guest? > > Of course it is ok if crash kernel support vt-d too.A crash kernel needs to be carefully configured anyway. For example it may not be started up on the boot processor: it gets started on whichever cpu initiated the crash. K.> Thanks > --jyh > > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Thursday, July 29, 2010 2:48 PM >> To: Jiang, Yunhong; Juergen Gross >> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Han, Weidong >> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >> >> Strictly speaking we should have a stab at disabling x2apic as well, but >> that''s harder. And not necessary for newer Linux kernels, which is what we >> will usually be kexec''ing to anyway. >> >> -- Keir >> >> On 29/07/2010 07:40, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: >> >>> It''s not a dom0, it''s a kexec''ed crash kernel. We should be reinstating DMAR >>> before jumping into a native kernel. I will sort out a fix. >>> >>> -- Keir >>> >>> On 29/07/2010 07:31, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >>> >>>> A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will >>>> not control interrupt controller, either xapic, or x2apic. Shouldn''t this >>>> be >>>> commented out in pvops dom0? >>>> >>>> What''s the panic point in your environment? Is it the following code? If >>>> yes, >>>> that means you enable x2apic in BIOS and you can workaround this issue by >>>> disable x2apic in BIOS. >>>> >>>> if (x2apic_preenabled) >>>> panic("x2apic: enabled by BIOS but kernel init failed."); >>>> >>>> Thanks >>>> --jyh >>>> >>>>> -----Original Message----- >>>>> From: xen-devel-bounces@lists.xensource.com >>>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >>>>> Sent: Wednesday, July 28, 2010 8:14 PM >>>>> To: Keir Fraser >>>>> Cc: xen-devel@lists.xensource.com >>>>> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >>>>> >>>>> On 07/28/2010 01:39 PM, Keir Fraser wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >> wrote: >>>>>> >>>>>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >>>>> wrote: >>>>>>>> >>>>>>>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>>>>>>> This leads to a programmed panic in the crash kernel later in case of >>>>>>>>> a >>>>>>>>> panic in dom0... >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> BTW: seen in unstable AND 4.0 >>>>>>>> >>>>>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>>>>>>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>>>>>>> Presumably bad stuff would happen if it did. >>>>>>> >>>>>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>>>>> The crash kernel OTOH should not panic due to the trashed entry! >>>>>>> What is the correct solution here? >>>>>> >>>>>> Could provide a cmdline option to not nobble the DMAR? >>>>> >>>>> That''s a possibility. >>>>> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >>>>> running under xen. This would remove the requirement for zapping the ACPI >>>>> table. IMO it''s always a bad idea to change data of a deeper layer... >>>>> >>>>>> >>>>>>> The crash kernel expects a valid DMAR entry, as following code in >>>>>>> enable_IR_x2apic() suggests: >>>>>> >>>>>> I don''t know what that function does, nor how the error path below >>>>>> depends >>>>>> on DMAR. DMAR isn''t mentioned in the below code. >>>>> >>>>> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >>>>> >>>>> void __init enable_IR_x2apic(void) >>>>> { >>>>> unsigned long flags; >>>>> struct IO_APIC_route_entry **ioapic_entries = NULL; >>>>> int ret, x2apic_enabled = 0; >>>>> int dmar_table_init_ret = 0; >>>>> >>>>> #ifdef CONFIG_INTR_REMAP >>>>> dmar_table_init_ret = dmar_table_init(); >>>>> if (dmar_table_init_ret) >>>>> pr_debug("dmar_table_init() failed with %d:\n", >>>>> dmar_table_init_ret); >>>>> #endif >>>>> >>>>> ioapic_entries = alloc_ioapic_entries(); >>>>> if (!ioapic_entries) { >>>>> pr_err("Allocate ioapic_entries failed\n"); >>>>> goto out; >>>>> } >>>>> >>>>> ret = save_IO_APIC_setup(ioapic_entries); >>>>> if (ret) { >>>>> pr_info("Saving IO-APIC state failed: %d\n", ret); >>>>> goto out; >>>>> } >>>>> >>>>> local_irq_save(flags); >>>>> mask_8259A(); >>>>> mask_IO_APIC_setup(ioapic_entries); >>>>> >>>>> if (dmar_table_init_ret) >>>>> ret = 0; >>>>> else >>>>> ret = enable_IR(); >>>>> >>>>> if (!ret) { >>>>> /* IR is required if there is APIC ID > 255 even when >>>>> running >>>>> * under KVM >>>>> */ >>>>> if (max_physical_apicid > 255 || !kvm_para_available()) >>>>> goto nox2apic; >>>>> /* >>>>> * without IR all CPUs can be addressed by IOAPIC/MSI >>>>> * only in physical mode >>>>> */ >>>>> x2apic_force_phys(); >>>>> } >>>>> >>>>> x2apic_enabled = 1; >>>>> >>>>> if (x2apic_supported() && !x2apic_mode) { >>>>> x2apic_mode = 1; >>>>> enable_x2apic(); >>>>> pr_info("Enabled x2apic\n"); >>>>> } >>>>> >>>>> nox2apic: >>>>> if (!ret) /* IR enabling failed */ >>>>> restore_IO_APIC_setup(ioapic_entries); >>>>> unmask_8259A(); >>>>> local_irq_restore(flags); >>>>> >>>>> out: >>>>> if (ioapic_entries) >>>>> free_ioapic_entries(ioapic_entries); >>>>> >>>>> if (x2apic_enabled) >>>>> return; >>>>> >>>>> if (x2apic_preenabled) >>>>> panic("x2apic: enabled by BIOS but kernel init failed."); >>>>> else if (cpu_has_x2apic) >>>>> pr_info("Not enabling x2apic, Intr-remapping init >>>>> failed.\n"); >>>>> } >>>>> >>>>> >>>>> dmar_table_init() will return -ENODEV if no DMAR record is found. >>>>> >>>>> >>>>> Juergen >>>>> >>>>> -- >>>>> Juergen Gross Principal Developer Operating Systems >>>>> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 >>>>> Fujitsu Technology Solutions e-mail: >>>>> juergen.gross@ts.fujitsu.com >>>>> Domagkstr. 28 Internet: ts.fujitsu.com >>>>> D-80807 Muenchen Company details: >>>>> ts.fujitsu.com/imprint.html >>>>> >>>>> _______________________________________________ >>>>> 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 >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen, Please try xen-unstable:21886, from our staging tree at http://xenbits.xen.org/staging/xen-unstable.hg It does a bunch of kexec cleanup, and should also correctly reinstate the DMAR table before calling the crash kernel. If it works okay we can consider it for backport to 4.0.1. Thanks, Keir On 29/07/2010 07:40, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> It''s not a dom0, it''s a kexec''ed crash kernel. We should be reinstating DMAR > before jumping into a native kernel. I will sort out a fix. > > -- Keir > > On 29/07/2010 07:31, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > >> A bit curios, why enable_IR_x2apic() will be called in dom0? IMO, dom0 will >> not control interrupt controller, either xapic, or x2apic. Shouldn''t this be >> commented out in pvops dom0? >> >> What''s the panic point in your environment? Is it the following code? If yes, >> that means you enable x2apic in BIOS and you can workaround this issue by >> disable x2apic in BIOS. >> >> if (x2apic_preenabled) >> panic("x2apic: enabled by BIOS but kernel init failed."); >> >> Thanks >> --jyh >> >>> -----Original Message----- >>> From: xen-devel-bounces@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >>> Sent: Wednesday, July 28, 2010 8:14 PM >>> To: Keir Fraser >>> Cc: xen-devel@lists.xensource.com >>> Subject: Re: [Xen-devel] ACPI-Tables corrupted? >>> >>> On 07/28/2010 01:39 PM, Keir Fraser wrote: >>>> >>>> >>>> >>>> On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >>>> >>>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@ts.fujitsu.com> >>> wrote: >>>>>> >>>>>>> As you can see, the DMAR eye-catcher is replaced by blanks! >>>>>>> This leads to a programmed panic in the crash kernel later in case of a >>>>>>> panic in dom0... >>>>>>> >>>>>>> Any ideas? >>>>>>> BTW: seen in unstable AND 4.0 >>>>>> >>>>>> Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always* >>>>>> *unconditionally* trashes the DMAR so that dom0 will not parse it. >>>>>> Presumably bad stuff would happen if it did. >>>>> >>>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>>> The crash kernel OTOH should not panic due to the trashed entry! >>>>> What is the correct solution here? >>>> >>>> Could provide a cmdline option to not nobble the DMAR? >>> >>> That''s a possibility. >>> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >>> running under xen. This would remove the requirement for zapping the ACPI >>> table. IMO it''s always a bad idea to change data of a deeper layer... >>> >>>> >>>>> The crash kernel expects a valid DMAR entry, as following code in >>>>> enable_IR_x2apic() suggests: >>>> >>>> I don''t know what that function does, nor how the error path below depends >>>> on DMAR. DMAR isn''t mentioned in the below code. >>> >>> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >>> >>> void __init enable_IR_x2apic(void) >>> { >>> unsigned long flags; >>> struct IO_APIC_route_entry **ioapic_entries = NULL; >>> int ret, x2apic_enabled = 0; >>> int dmar_table_init_ret = 0; >>> >>> #ifdef CONFIG_INTR_REMAP >>> dmar_table_init_ret = dmar_table_init(); >>> if (dmar_table_init_ret) >>> pr_debug("dmar_table_init() failed with %d:\n", >>> dmar_table_init_ret); >>> #endif >>> >>> ioapic_entries = alloc_ioapic_entries(); >>> if (!ioapic_entries) { >>> pr_err("Allocate ioapic_entries failed\n"); >>> goto out; >>> } >>> >>> ret = save_IO_APIC_setup(ioapic_entries); >>> if (ret) { >>> pr_info("Saving IO-APIC state failed: %d\n", ret); >>> goto out; >>> } >>> >>> local_irq_save(flags); >>> mask_8259A(); >>> mask_IO_APIC_setup(ioapic_entries); >>> >>> if (dmar_table_init_ret) >>> ret = 0; >>> else >>> ret = enable_IR(); >>> >>> if (!ret) { >>> /* IR is required if there is APIC ID > 255 even when >>> running >>> * under KVM >>> */ >>> if (max_physical_apicid > 255 || !kvm_para_available()) >>> goto nox2apic; >>> /* >>> * without IR all CPUs can be addressed by IOAPIC/MSI >>> * only in physical mode >>> */ >>> x2apic_force_phys(); >>> } >>> >>> x2apic_enabled = 1; >>> >>> if (x2apic_supported() && !x2apic_mode) { >>> x2apic_mode = 1; >>> enable_x2apic(); >>> pr_info("Enabled x2apic\n"); >>> } >>> >>> nox2apic: >>> if (!ret) /* IR enabling failed */ >>> restore_IO_APIC_setup(ioapic_entries); >>> unmask_8259A(); >>> local_irq_restore(flags); >>> >>> out: >>> if (ioapic_entries) >>> free_ioapic_entries(ioapic_entries); >>> >>> if (x2apic_enabled) >>> return; >>> >>> if (x2apic_preenabled) >>> panic("x2apic: enabled by BIOS but kernel init failed."); >>> else if (cpu_has_x2apic) >>> pr_info("Not enabling x2apic, Intr-remapping init >>> failed.\n"); >>> } >>> >>> >>> dmar_table_init() will return -ENODEV if no DMAR record is found. >>> >>> >>> Juergen >>> >>> -- >>> Juergen Gross Principal Developer Operating Systems >>> TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 >>> Fujitsu Technology Solutions e-mail: >>> juergen.gross@ts.fujitsu.com >>> Domagkstr. 28 Internet: ts.fujitsu.com >>> D-80807 Muenchen Company details: >>> ts.fujitsu.com/imprint.html >>> >>> _______________________________________________ >>> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/29/2010 12:24 PM, Keir Fraser wrote:> Juergen, > > Please try xen-unstable:21886, from our staging tree at > http://xenbits.xen.org/staging/xen-unstable.hg > > It does a bunch of kexec cleanup, and should also correctly reinstate the > DMAR table before calling the crash kernel. > > If it works okay we can consider it for backport to 4.0.1.crash kernel comes up now. And yes, please do a backport to 4.0.1! Thanks, Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 28.07.10 at 14:45, Keir Fraser <keir.fraser@eu.citrix.com> wrote: > On 28/07/2010 13:13, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote: > >>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>> The crash kernel OTOH should not panic due to the trashed entry! >>>> What is the correct solution here? >>> >>> Could provide a cmdline option to not nobble the DMAR? >> >> That''s a possibility. >> I wonder whether it wouldn''t be better to let dom0 decide not to use it if >> running under xen. This would remove the requirement for zapping the ACPI >> table. IMO it''s always a bad idea to change data of a deeper layer... > > If we don''t zap the DMAR then every existing dom0 kernel will fail with new > hypervisor.Who decided that this zapping is going to work on all systems in the future? E.g. I can''t see why a BIOS shouldn''t decide to put most of the ACPI tables in chipset write protected memory, if a chipset offers such? In such an environment, Dom0 would still see the original signature - shouldn''t we thus correct the original mistake of fiddling with the ACPI tables as we now have to touch that code anyway? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/08/2010 14:39, "Jan Beulich" <JBeulich@novell.com> wrote:>> If we don''t zap the DMAR then every existing dom0 kernel will fail with new >> hypervisor. > > Who decided that this zapping is going to work on all systems in the > future?Someone at Intel.> E.g. I can''t see why a BIOS shouldn''t decide to put most of > the ACPI tables in chipset write protected memory, if a chipset offers > such? In such an environment, Dom0 would still see the original > signature - shouldn''t we thus correct the original mistake of fiddling > with the ACPI tables as we now have to touch that code anyway?Well it''s harmless to try zapping it I think, now we reinstate it on kexec. Trying to be smarter in dom0 *as well* is plausible I guess. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Seemingly Similar Threads
- [PATCH]x86:x2apic: Disable x2apic on x86-32 permanently
- [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
- Bug#625438: [PATCH] xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables
- Bug#625438: [PATCH] xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables
- Warning: Your BIOS is broken