On Fri, Jun 06, 2025, Peter Zijlstra wrote: > On Thu, Jun 05, 2025 at 10:19:41AM -0700, Josh Poimboeuf wrote: > > diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S > > index 29c5c32c16c3..5d1eef193b79 100644 > > --- a/arch/x86/entry/entry_64_fred.S > > +++ b/arch/x86/entry/entry_64_fred.S > > @@ -112,11 +112,12 @@ SYM_FUNC_START(asm_fred_entry_from_kvm) > > push %rax /* Return RIP */ > > push $0 /* Error code, 0 for IRQ/NMI */ > > > > - PUSH_AND_CLEAR_REGS clear_bp=0 unwind_hint=0 > > + PUSH_AND_CLEAR_REGS clear_callee=0 unwind_hint=0 > > movq %rsp, %rdi /* %rdi -> pt_regs */ > > call __fred_entry_from_kvm /* Call the C entry point */ > > - POP_REGS > > - ERETS > > + addq $C_PTREGS_SIZE, %rsp > > + > > + ALTERNATIVE "mov %rbp, %rsp", __stringify(ERETS), X86_FEATURE_FRED > > So... I was wondering.. do we actually ever need the ERETS?
Yes, to unblock NMIs, because NMIs are blocked on VM-Exit due to NMI. The !X86_FEATURE_FRED path can use RET (instead of IRET) because NMIs are routed through vmx_do_nmi_irqoff(), as proposed in this version[*], after you pointed out that the FRED entry doesn't have the legacy NMI madness. [*] https://lore.kernel.org/all/[email protected]
