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@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
|
Home