Re: [Xen-devel] ACPI-Tables corrupted?

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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