[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/SMP: don't try to stop already stopped CPUs
>>> On 17.06.19 at 20:27, <andrew.cooper3@xxxxxxxxxx> wrote: > On 17/06/2019 18:55, Andrew Cooper wrote: >> On 17/06/2019 18:39, Andrew Cooper wrote: >>> On 29/05/2019 11:17, Jan Beulich wrote: >>>> In particular with an enabled IOMMU (but not really limited to this >>>> case), trying to invoke fixup_irqs() after having already done >>>> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea: >>>> >>>> RIP: e008:[<ffff82d08026a036>] >>>> amd_iommu_read_ioapic_from_ire+0xde/0x113 >>>> RFLAGS: 0000000000010006 CONTEXT: hypervisor (d0v0) >>>> rax: ffff8320291de00c rbx: 0000000000000003 rcx: ffff832035000000 >>>> rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff82d0805ca840 >>>> rbp: ffff83009e8a79c8 rsp: ffff83009e8a79a8 r8: 0000000000000000 >>>> r9: 0000000000000004 r10: 000000000008b9f9 r11: 0000000000000006 >>>> r12: 0000000000010000 r13: 0000000000000003 r14: 0000000000000000 >>>> r15: 00000000fffeffff cr0: 0000000080050033 cr4: 00000000003406e0 >>>> cr3: 0000002035d59000 cr2: ffff88824ccb4ee0 >>>> fsb: 00007f2143f08840 gsb: ffff888256a00000 gss: 0000000000000000 >>>> ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 >>>> Xen code around <ffff82d08026a036> > (amd_iommu_read_ioapic_from_ire+0xde/0x113): >>>> ff 07 00 00 39 d3 74 02 <0f> 0b 41 81 e4 00 f8 ff ff 8b 10 89 d0 25 00 00 >>>> Xen stack trace from rsp=ffff83009e8a79a8: >>>> ... >>>> Xen call trace: >>>> [<ffff82d08026a036>] amd_iommu_read_ioapic_from_ire+0xde/0x113 >>>> [<ffff82d08026bf7b>] iommu_read_apic_from_ire+0x10/0x12 >>>> [<ffff82d08027f718>] io_apic.c#modify_IO_APIC_irq+0x5e/0x126 >>>> [<ffff82d08027f9c5>] io_apic.c#unmask_IO_APIC_irq+0x2d/0x41 >>>> [<ffff82d080289bc7>] fixup_irqs+0x320/0x40b >>>> [<ffff82d0802a82c4>] smp_send_stop+0x4b/0xa8 >>>> [<ffff82d0802a7b2f>] machine_restart+0x98/0x288 >>>> [<ffff82d080252242>] console_suspend+0/0x28 >>>> [<ffff82d0802b01da>] do_general_protection+0x204/0x24e >>>> [<ffff82d080385a3d>] x86_64/entry.S#handle_exception_saved+0x68/0x94 >>>> [<00000000aa5b526b>] 00000000aa5b526b >>>> [<ffff82d0802a7c7d>] machine_restart+0x1e6/0x288 >>>> [<ffff82d080240f75>] hwdom_shutdown+0xa2/0x11d >>>> [<ffff82d08020baa2>] domain_shutdown+0x4f/0xd8 >>>> [<ffff82d08023fe98>] do_sched_op+0x12f/0x42a >>>> [<ffff82d08037e404>] pv_hypercall+0x1e4/0x564 >>>> [<ffff82d080385432>] lstar_enter+0x112/0x120 >>>> >>>> Don't call fixup_irqs() and don't send any IPI if there's only one >>>> online CPU anyway, and don't call __stop_this_cpu() at all when the CPU >>>> we're on was already marked offline (by a prior invocation of >>>> __stop_this_cpu()). >>>> >>>> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>> It is probably worth noting that the above stack trace is a cascade >>> fault, where we took a #GP fault in the middle of the EFI firmware, and >>> then tried restarting a second time. >>> >>> For the change it is an improvement, so Acked-by: Andrew Cooper >>> <andrew.cooper3@xxxxxxxxxx> >>> >>> There are further fixes needing (which have been on my todo list for >>> rather too long) to avoid any local_irq_enable() on the shutdown path, >>> because during a crash (especially one in the middle of a vcpu context >>> switch), its not safe to re-enable interrupts. >>> >>> The only solution I've got involves using NMI based IPIs/shootdowns. >> >> /sigh and no sooner as I tried testing this, I found the next piece of >> fallout: >> >> [ 90.447906] reboot: Restarting system >> (XEN) Hardware Dom0 shutdown: rebooting machine >> (XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[<00000000aa5b526b>] 00000000aa5b526b >> (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor >> (XEN) rax: 00000000aa985950 rbx: 0000000000000000 rcx: 00000000aa5b7010 >> (XEN) rdx: 0000000000000000 rsi: ffff83009e827fff rdi: 00000000003506e0 >> (XEN) rbp: ffff83009e827c70 rsp: ffff83009e827bb0 r8: 00000000aa5b7048 >> (XEN) r9: 0000000000000000 r10: ffff83009e827c88 r11: 0f0f0f0f0f0f0f0f >> (XEN) r12: 00000000fffffffe r13: 0000000000000cf9 r14: 0000000000000000 >> (XEN) r15: 0000000000000065 cr0: 0000000080050033 cr4: 00000000003506e0 >> (XEN) cr3: 00000010f5218000 cr2: ffff88825990c800 >> (XEN) fsb: 0000000000000000 gsb: ffff888266a00000 gss: 0000000000000000 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 >> (XEN) Xen code around <00000000aa5b526b> (00000000aa5b526b): >> (XEN) 8d 0d a7 1d 00 00 33 d2 <ff> 90 40 01 00 00 48 8b 05 d0 1d 00 00 48 >> 83 > c4 >> (XEN) Xen stack trace from rsp=ffff83009e827bb0: >> (XEN) 000000000000001f 00000000003506e0 ffff83009e827c00 0000000000000206 >> (XEN) ffff82d08027d96a 00000000aa5b51f7 0000000000000286 ffff83009e827c40 >> (XEN) 000000009e817000 0000000000000cf9 ffff83009e827c30 ffff82d080201327 >> (XEN) 00000000ffffffff ffff82d08020162e 0000000000000000 00000000fffffffe >> (XEN) ffff83009e827c70 ffff82d0802015ff 000000009e817000 ffff83009e827c78 >> (XEN) ffff82d0802a372a 0000000080000000 0000000000000000 ffff83009e827c88 >> (XEN) ffff83009e827cd8 ffff82d0802a3045 ffff82d0802a3045 ffff83009e827c98 >> (XEN) 000000008028454c 000082d080387851 0000000000000000 ffff82d080387851 >> (XEN) 0000000000000000 ffff83009e827d98 00000000000000fb 0000000080000000 >> (XEN) 0000000000000000 ffff83009e827ce8 ffff82d0802a3105 ffff83009e827d08 >> (XEN) ffff82d08023cdaa ffff82d080387851 0000000000000000 ffff83009e827d18 >> (XEN) ffff82d0802a37da ffff83009e827d88 ffff82d080283fb4 ffff82d080387851 >> (XEN) ffff82d080387845 0000000000000000 ffff82d080387845 ffff82d080387851 >> (XEN) ffff82d080387845 ffff82d080387851 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 ffff83009e827fff 0000000000000000 00007cff617d8247 >> (XEN) ffff82d0803878ba ffff82d080933900 0000000000000000 000000204b161644 >> (XEN) ffff8310f5206ef8 ffff83009e827e40 ffff8310f5206ea0 0000002065fe762e >> (XEN) 000000204bbfce6e ffff82d08095c3e0 ffff83009e827ef8 0000000000000000 >> (XEN) 0000000000000048 0000000000000000 ffff83009e827fff ffff8310f5206ef8 >> (XEN) 000000fb00000000 ffff82d0802e1bc5 000000000000e008 0000000000000206 >> (XEN) Xen call trace: >> (XEN) [<00000000aa5b526b>] 00000000aa5b526b >> (XEN) [<ffff82d0802a3045>] machine_restart+0x1ef/0x2a4 >> (XEN) [<ffff82d0802a3105>] send_IPI_mask+0/0xc >> (XEN) [<ffff82d08023cdaa>] smp_call_function_interrupt+0x95/0xb8 >> (XEN) [<ffff82d0802a37da>] call_function_interrupt+0x35/0x37 >> (XEN) [<ffff82d080283fb4>] do_IRQ+0xa7/0x697 >> (XEN) [<ffff82d0803878ba>] common_interrupt+0x10a/0x120 >> (XEN) [<ffff82d0802e1bc5>] cpu_idle.c#acpi_idle_do_entry+0xa4/0xb5 >> (XEN) [<ffff82d0802e20ae>] cpu_idle.c#acpi_processor_idle+0x313/0x590 >> (XEN) [<ffff82d080274f8c>] domain.c#idle_loop+0xa2/0xb1 >> (XEN) >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) GENERAL PROTECTION FAULT >> (XEN) [error_code=0000] >> (XEN) **************************************** >> (XEN) >> (XEN) Reboot in five seconds... >> (XEN) Executing kexec image on cpu0 >> (XEN) Shot down all CPUs >> (XEN) Assertion 'offset == (val & (INTREMAP_ENTRIES - 1))' failed at > iommu_intr.c:567 >> (XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[<ffff82d080266844>] > amd_iommu_read_ioapic_from_ire+0xd0/0x131 >> (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor >> (XEN) rax: 0000000000000000 rbx: 0000000000000014 rcx: ffff832005d68010 >> (XEN) rdx: ffff832005d68000 rsi: 0000000000000000 rdi: ffff82d080942a00 >> (XEN) rbp: ffff83009e827948 rsp: ffff83009e827928 r8: ffff82d0808074c0 >> (XEN) r9: ffff82d080942a08 r10: 0000000000000000 r11: 0000000000000001 >> (XEN) r12: 0000000000010000 r13: 0000000000000001 r14: 0000000000000000 >> (XEN) r15: 0000000000000000 cr0: 0000000080050033 cr4: 00000000003506e0 >> (XEN) cr3: 00000010f5218000 cr2: ffff88825990c800 >> (XEN) fsb: 0000000000000000 gsb: ffff888266a00000 gss: 0000000000000000 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 >> (XEN) Xen code around <ffff82d080266844> > (amd_iommu_read_ioapic_from_ire+0xd0/0x131): >> (XEN) 07 00 00 41 39 c5 74 02 <0f> 0b 41 81 e4 00 f8 ff ff 0f b6 11 c0 ea >> 02 > 83 >> (XEN) Xen stack trace from rsp=ffff83009e827928: >> (XEN) ffff82d08027c244 0000000000000014 ffff82d080806980 0000000000000000 >> (XEN) ffff83009e827958 ffff82d0802687a7 ffff83009e827968 ffff82d08027c25b >> (XEN) ffff83009e827998 ffff82d08027cefb 0000000000000000 0000000000000002 >> (XEN) ffff82d080806980 ffff82d080806980 ffff83009e8279c8 ffff82d08027d8c8 >> (XEN) ffff83009e827fff 0000000000010000 0000000000000002 0000000000000000 >> (XEN) ffff83009e8279f8 ffff82d08027d9ce 00000000000003e8 ffff82d080943b80 >> (XEN) 0000000000000000 ffff83009e827fff ffff83009e827a18 ffff82d08027dd30 >> (XEN) ffff83009e827a18 ffff82d0802a3626 ffff83009e827a38 ffff82d080270a79 >> (XEN) 0000000000000003 ffff82d08043f858 ffff83009e827a58 ffff82d08021dd74 >> (XEN) 0000000000000206 0000000000000296 ffff83009e827ac8 ffff82d08024db40 >> (XEN) ffff83009e827aa8 ffff82d000000010 ffff83009e827ad8 ffff83009e827a88 >> (XEN) ffff83009e827aa8 0000000000000000 ffff83009e827fff 0000000000000000 >> (XEN) ffff8310f3e00000 0000000000000002 ffff83009e827b08 0000000000000000 >> (XEN) ffff83009e827af8 ffff82d0802ab1b8 ffff82d080387979 ffff82d08038796d >> (XEN) ffff8310f4c08000 0000000000000000 00007cff617d84d7 ffff82d080387a3d >> (XEN) 0000000000000065 0000000000000000 0000000000000cf9 00000000fffffffe >> (XEN) ffff83009e827c70 0000000000000000 0f0f0f0f0f0f0f0f ffff83009e827c88 >> (XEN) 0000000000000000 00000000aa5b7048 00000000aa985950 00000000aa5b7010 >> (XEN) 0000000000000000 ffff83009e827fff 00000000003506e0 0000000d00000000 >> (XEN) 00000000aa5b526b 000000000000e008 0000000000010246 ffff83009e827bb0 >> (XEN) Xen call trace: >> (XEN) [<ffff82d080266844>] amd_iommu_read_ioapic_from_ire+0xd0/0x131 >> (XEN) [<ffff82d0802687a7>] iommu_read_apic_from_ire+0x10/0x12 >> (XEN) [<ffff82d08027c25b>] io_apic.c#io_apic_read+0x17/0x5f >> (XEN) [<ffff82d08027cefb>] __ioapic_read_entry+0x2f/0x55 >> (XEN) [<ffff82d08027d8c8>] io_apic.c#clear_IO_APIC_pin+0x1a/0xf3 >> (XEN) [<ffff82d08027d9ce>] io_apic.c#clear_IO_APIC+0x2d/0x60 >> (XEN) [<ffff82d08027dd30>] disable_IO_APIC+0xd/0x7e >> (XEN) [<ffff82d080270a79>] machine_crash_shutdown+0x228/0x292 >> (XEN) [<ffff82d08021dd74>] kexec_crash+0x3f/0x5b >> (XEN) [<ffff82d08024db40>] panic+0x117/0x12f >> (XEN) [<ffff82d0802ab1b8>] do_general_protection+0x22b/0x234 >> (XEN) [<ffff82d080387a3d>] x86_64/entry.S#handle_exception_saved+0x68/0x94 >> (XEN) [<00000000aa5b526b>] 00000000aa5b526b >> (XEN) [<ffff82d0802a3045>] machine_restart+0x1ef/0x2a4 >> (XEN) [<ffff82d0802a3105>] send_IPI_mask+0/0xc >> (XEN) [<ffff82d08023cdaa>] smp_call_function_interrupt+0x95/0xb8 >> (XEN) [<ffff82d0802a37da>] call_function_interrupt+0x35/0x37 >> (XEN) [<ffff82d080283fb4>] do_IRQ+0xa7/0x697 >> (XEN) [<ffff82d0803878ba>] common_interrupt+0x10a/0x120 >> (XEN) [<ffff82d0802e1bc5>] cpu_idle.c#acpi_idle_do_entry+0xa4/0xb5 >> (XEN) [<ffff82d0802e20ae>] cpu_idle.c#acpi_processor_idle+0x313/0x590 >> (XEN) [<ffff82d080274f8c>] domain.c#idle_loop+0xa2/0xb1 >> (XEN) >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) Assertion 'offset == (val & (INTREMAP_ENTRIES - 1))' failed at > iommu_intr.c:567 >> (XEN) **************************************** >> (XEN) >> >> >> I think we need a similar adjustment in nmi_shootdown_cpus() > > Yes. With this fix included, then we successfully transition into the > crash kernel. I think it would be best to fold into this patch, given > its direct relevance. Will do. Jan > Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > > diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c > index 01e48a1..f9772dc 100644 > --- a/xen/arch/x86/crash.c > +++ b/xen/arch/x86/crash.c > @@ -169,15 +169,20 @@ static void nmi_shootdown_cpus(void) > */ > iommu_crash_shutdown(); > > - __stop_this_cpu(); > + if ( num_online_cpus() > 1 ) > + { > + __stop_this_cpu(); > > - /* This is a bit of a hack due to the problems with the x2apic_enabled > - * variable, but we can't do any better without a significant > refactoring > - * of the APIC code */ > - x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC); > + /* > + * This is a bit of a hack due to the problems with the > x2apic_enabled > + * variable, but we can't do any better without a significant > + * refactoring of the APIC code > + */ > + x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC); > > - disable_IO_APIC(); > - hpet_disable(); > + disable_IO_APIC(); > + hpet_disable(); > + } > } > > void machine_crash_shutdown(void) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |