> > > > + * "Restore" RSP from RBP, even though IRET has already unwound > > > > RSP to > > > > + * the correct value. objtool doesn't know the callee will IRET and, > > > > + * without the explicit restore, thinks the stack is getting walloped. > > > > + * Using an unwind hint is problematic due to x86-64's dynamic > > > > alignment. > > > > + */ > > > > + mov %_ASM_BP, %_ASM_SP > > > > + pop %_ASM_BP > > > > + RET > > > > > > For NMI, after this RET instruction, we continue to block NMIs. IRET > > instead? > > > > No, IRET has already been done by the kernel-provided handler, e.g. > > asm_exc_nmi_kvm_vmx() > > by way of error_return(). That's why the CALL above (that got snipped) is > > preceded > > by the creation of a synthetic NMI/IRQ stack frame: the target returns from > > the CALL > > via IRET, not RET. > > > You're right, this assembly makes another call into the asm entry point, which > returns here with IRET. Like IRET for IDT, we _need_ ERETS for FRED to unblock NMI ASAP. However a FRED stack frame has way more information than an IDT stack frame, thus it's complicated to create a FRED stack frame with assembly. So I prefer "INT $2" for FRED now. I will post the FRED patch set soon, lets sync up on this afterwards. Xin
