search for: do_nmi

Remove the do_nmi() call from the vmexit logic, as the NMI is held pending and will be handled in the context of the host when the STGI instruction is executed. This patch only modifies AMD-V code. This patch is required even without the other Xenoprofile patches applied. Applies cleanly to c/s 11831. Please app...

...:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the > vCPU when it reaches IRET. This patch is overcomplicated IMO. Just do the magic incantation in C from do_nmi or from here: /* * For ease of testing, unmask NMIs right away. Disabled by * default because IRET is very expensive. If you do the latter, you'll need to handle the case where the NMI came from user mode. The ideal solution is do_nmi, I think. if (static_cpu_has(...

...een hundreds of iterations of this VMEXIT/VMENTER loop before the HVM guest resumes normal operation. Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> -- Changes since v2 * Switch from ''int $2'' to do_nmi() * Reworked commit message to more clearly explain the problem diff -r 2489c2926698 -r d7ea938044ac xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2269,6 +2269,14 @@ void vmx_vmexit_handler(struct cpu_user_ vector = intr_info & INTR_...

...MACHINE: x86_64 (2660 Mhz) MEMORY: 23.6 GB PANIC: "Oops: 0000 [1] SMP " (check log for details) crash> bt -a PID: 0 TASK: ffffffff802ffae0 CPU: 0 COMMAND: "swapper" #0 [ffffffff8043ef20] crash_nmi_callback at ffffffff8007a3bf #1 [ffffffff8043ef40] do_nmi at ffffffff8006585a #2 [ffffffff8043ef50] nmi at ffffffff80064ebf [exception RIP: acpi_processor_idle+579] RIP: ffffffff8019765e RSP: ffffffff803f1f48 RFLAGS: 00000093 RAX: 000000000073111a RBX: 000000000073111a RCX: 0000000000000808 RDX: 0000000000000815 RSI: 0000000000000003...

..._to_usermode, SYM_L_GLOBAL) ud2 1: #endif + + /* + * This code path is used by the NMI handler, so check if NMIs + * need to be re-enabled when running as an SEV-ES guest. + */ + SEV_ES_IRET_CHECK + POP_REGS pop_rdi=0 /* @@ -1474,6 +1482,8 @@ SYM_CODE_START(nmi) movq $-1, %rsi call do_nmi + SEV_ES_NMI_COMPLETE + /* * Return back to user mode. We must *not* do the normal exit * work, because we don't want to enable interrupts. @@ -1599,6 +1609,7 @@ nested_nmi_out: popq %rdx /* We are returning to kernel mode, so this cannot result in a fault. */ + SEV_ES_NMI_COMP...

...you get NMI. If the NMI does its own GHCB access [0], it will clobber the outer #VC?a state, resulting in a failure when VMGEXIT happens. There?s a related failure mode if the NMI is after the VMGEXIT but before the result is read. I suspect you can fix this by saving the GHCB at the beginning of do_nmi and restoring it at the end. This has the major caveat that it will not work if do_nmi comes from user mode and schedules, but I don?t believe this can happen. [0] Due to the NMI_COMPLETE catastrophe, there is a 100% chance that this happens.

...l <jroedel at suse.de> When running under SEV-ES the kernel has to tell the hypervisor when to open the NMI window again after an NMI was injected. This is done with an NMI-complete message to the hypervisor. Add code to the kernels NMI handler to send this message right at the beginning of do_nmi(). This always allows nesting NMIs. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/sev-es.h | 2 ++ arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/nmi.c | 7 +++++++ arch/x86/kernel/sev-es.c | 18 ++++++++++++++++++ 4 files changed, 2...

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around

...d also a patch not posted FAIK (oprofile-0.9.1-fix-hvm-addr-overlap.patch) which is in the attached tar.bz2 file. hvm_xenoprofile_1.patch - The first patch is merely the same patch that I posted a few weeks ago. The STGI code is moved from the exits.S files, and into the vmexit handler. The extra do_nmi() is removed allowing the host to handle the NMI when the stgi instruction is executed. This patch allows the second patch to properly set "guest NMI" flag for the oprofile code to determine proper rip/eip and mode. hvm_xenoprofile_2.patch - The second patch adds the actual xenoprofile...

...Kaboom. > > > > How are you dealing with this? Ultimately, I think that NMI will need > > to turn off IST before engaging in any funny business. Let me ponder > > this a bit. > > Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry > in do_nmi() (thanks to Davin Kaplan for the idea). It might cause > one of the IST stacks to be unused during nesting, but that is fine. The > stack memory for #VC is only allocated when SEV-ES is active (in an > SEV-ES VM). Blech. It probably works, but still, yuck. It's a bit sad that we se...

Hi I am using oprofile 0.9.3 on xen cs 16540 on an Intel system. When I look at the top "hot" functions, I see p2m_change_type being one of the top function in xen-syms. This function is only in the svm (AMD) code and should not appear on an Intel system. I see that this function is not being clled at all when I am running my apps as I have put printk in the functions and they do

...029bd5 0000000000000046 0000000000000004 ffffffff8031fad8 Call Trace:<ffffffff80111860>{show_stack+241} <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} <ffffffff8011d055>{nmi_watchdog_tick+210} <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d10b>{do_nmi+115} <ffffffff80111173>{paranoid_exit+0} <ffffffff8030a9aa>{.text.lock.spinlock+46} <ffffffff8013b98a>{it_real_fn+0} <ffffffff8013b98a>{it_real_fn+0} Code: 0f 0b dd da 31 80 ff ff ff ff 4b 00 31 ff e8 83 c1 fe ff e8 RI...

...linkage void nmi(void); +asmlinkage void int3(void); +asmlinkage void overflow(void); +asmlinkage void bounds(void); +asmlinkage void invalid_op(void); + +asmlinkage void do_divide_error (struct pt_regs *, unsigned long); +asmlinkage void do_debug (struct pt_regs *, unsigned long); +asmlinkage void do_nmi (struct pt_regs *, unsigned long); +asmlinkage void do_int3 (struct pt_regs *, unsigned long); +asmlinkage void do_overflow (struct pt_regs *, unsigned long); +asmlinkage void do_bounds (struct pt_regs *, unsigned long); +asmlinkage void do_invalid_op (struct pt_regs *, unsigned long); + +extern in...

...gets shifted > #VC > > Kaboom. > > How are you dealing with this? Ultimately, I think that NMI will need > to turn off IST before engaging in any funny business. Let me ponder > this a bit. Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry in do_nmi() (thanks to Davin Kaplan for the idea). It might cause one of the IST stacks to be unused during nesting, but that is fine. The stack memory for #VC is only allocated when SEV-ES is active (in an SEV-ES VM). Regards, Joerg

On Tue, Apr 28, 2020 at 05:16:48PM +0200, Joerg Roedel wrote: > +bool sev_es_active(void) > +{ > + return !!(sev_status & MSR_AMD64_SEV_ES_ENABLED); > +} > +EXPORT_SYMBOL_GPL(sev_es_active); I don't see this being used in modules anywhere in the patchset. Or am I missing something? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

...t; How are you dealing with this? Ultimately, I think that NMI will need > > > to turn off IST before engaging in any funny business. Let me ponder > > > this a bit. > > > > Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry > > in do_nmi() (thanks to Davin Kaplan for the idea). It might cause > > one of the IST stacks to be unused during nesting, but that is fine. The > > stack memory for #VC is only allocated when SEV-ES is active (in an > > SEV-ES VM). > > Blech. It probably works, but still, yuck. It...

...] perf_event_overflow+0x14/0x20 [ 9227.509800] [<ffffffff81032fda>] intel_pmu_handle_irq+0x1ba/0x3a0 [ 9227.509802] [<ffffffff8102a6db>] perf_event_nmi_handler+0x2b/0x50 [ 9227.509804] [<ffffffff810184c0>] nmi_handle+0x80/0x120 [ 9227.509805] [<ffffffff81018a6a>] default_do_nmi+0x4a/0x140 [ 9227.509806] [<ffffffff81018be8>] do_nmi+0x88/0xd0 [ 9227.509808] [<ffffffff817b3ae1>] end_repeat_nmi+0x1e/0x2e [ 9227.509810] [<ffffffff817b0f1a>] ? _raw_spin_lock_irqsave+0x4a/0x90 [ 9227.509812] [<ffffffff817b0f1a>] ? _raw_spin_lock_irqsave+0x4a/0x90 [ 92...

...KPROBE_EXIT = ENTRY(coprocessor_error) RING0_INT_FRAME @@ -715,7 +715,7 @@ debug_stack_correct: call do_debug jmp ret_from_exception CFI_ENDPROC -.previous +KPROBE_EXIT = /* * NMI is doubly nasty. It can happen _while_ we're handling @@ -795,12 +795,12 @@ nmi_16bit_stack: call do_nmi RESTORE_REGS lss 12+4(%esp), %esp # back to 16bit stack -1: INTERRUPT_RETURN - CFI_ENDPROC -.section __ex_table,"a" +1: iret + CFI_ENDPROC +.pushsection __ex_table,"a" .align 4 .long 1b,iret_exc -.previous +.popsection = #ifdef CONFIG_PARAVIRT ENTRY(nopara_iret) @@...

...KPROBE_EXIT = ENTRY(coprocessor_error) RING0_INT_FRAME @@ -715,7 +715,7 @@ debug_stack_correct: call do_debug jmp ret_from_exception CFI_ENDPROC -.previous +KPROBE_EXIT = /* * NMI is doubly nasty. It can happen _while_ we're handling @@ -795,12 +795,12 @@ nmi_16bit_stack: call do_nmi RESTORE_REGS lss 12+4(%esp), %esp # back to 16bit stack -1: INTERRUPT_RETURN - CFI_ENDPROC -.section __ex_table,"a" +1: iret + CFI_ENDPROC +.pushsection __ex_table,"a" .align 4 .long 1b,iret_exc -.previous +.popsection = #ifdef CONFIG_PARAVIRT ENTRY(nopara_iret) @@...