|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] ACPI-Tables corrupted?
On 29/07/2010 08:37, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 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@xxxxxxxxxxxxx] >> Sent: Thursday, July 29, 2010 2:48 PM >> To: Jiang, Yunhong; Juergen Gross >> Cc: Jeremy Fitzhardinge; xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >>>>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Juergen Gross >>>>> Sent: Wednesday, July 28, 2010 8:14 PM >>>>> To: Keir Fraser >>>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx >>>>> 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@xxxxxxxxxxxxxx> >> wrote: >>>>>> >>>>>>> On 07/28/2010 12:03 PM, Keir Fraser wrote: >>>>>>>> On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx> >>>>> 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@xxxxxxxxxxxxxx >>>>> Domagkstr. 28 Internet: ts.fujitsu.com >>>>> D-80807 Muenchen Company details: >>>>> ts.fujitsu.com/imprint.html >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx >>>>> http://lists.xensource.com/xen-devel >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@xxxxxxxxxxxxxxxxxxx >>> http://lists.xensource.com/xen-devel >> > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |