search for: self_nmi

...; diff -r 8b93ac0c93f3 -r f3adcb7d84ea xen/arch/x86/nmi.c --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -482,13 +482,14 @@ void nmi_watchdog_tick(struct cpu_user_r * 8-3 and 8-4 in IA32 Reference Manual Volume 3. We send the IPI to * our own APIC ID explicitly which is valid. */ -void self_nmi(void) +void self_nmi(void) { + unsigned long flags; u32 id = get_apic_id(); - local_irq_disable(); + local_irq_save(flags); apic_wait_icr_idle(); apic_icr_write(APIC_DM_NMI | APIC_DEST_PHYSICAL, id); - local_irq_enable(); + local_irq_restore(flags); } static void...

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exi...

...et up another NMI at the LAPIC. Even when the LAPIC has been disabled, the ID and command registers are still usable. As a result, we can deliberately queue up a new NMI to re-interrupt us later if NMIs get unlatched. Because of the call to __stop_this_cpu(), we have to hand craft self_nmi() to be safe from General Protection Faults. * Fall into infinite loop. machine_kexec() will: * Swap the MCE handlers to be a nop. We cannot prevent MCEs from being delivered when we pass off to the crash kernel, and the less Xen context is being touched the better. * Explici...

This issue I am encountering seems to only happen on multi-socket machines. It also does not help that the only multi-socket box I have is an Romley-EP (so two socket SandyBridge CPUs). The other SandyBridge boxes I''ve (one socket) are not showing this. Granted they are also a different model (42). The problem is that when I run ''perf top'' within an SMP PVHVM guest,