|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 |