Re: [PATCH 03/22] x86/kvm: Fix frame pointer usage in vmx_vmenter()

[Josh Poimboeuf]

On Mon, Jul 15, 2019 at 11:04:03AM +0200, Paolo Bonzini wrote:
> On 15/07/19 02:36, Josh Poimboeuf wrote:
> > With CONFIG_FRAME_POINTER, vmx_vmenter() needs to do frame pointer setup
> > before calling kvm_spurious_fault().
> > 
> > Fixes the following warning:
> > 
> >   arch/x86/kvm/vmx/vmenter.o: warning: objtool: vmx_vmenter()+0x14: call without frame pointer save/setup
> > 
> > Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> 
> This is not enough, because the RSP value must match what is computed at
> this place:
> 
>         /* Adjust RSP to account for the CALL to vmx_vmenter(). */
>         lea -WORD_SIZE(%_ASM_SP), %_ASM_ARG2
>         call vmx_update_host_rsp

Ah, that is surprising :-)

And then there's this, which overwrites the frame pointer anyway:

	mov VCPU_RBP(%_ASM_AX), %_ASM_BP

Would it make sense to remove the call to vmx_vmenter() altogether, and
just either embed it in __vmx_vcpu_run(), or jmp back and forth to it
from __vmx_vcpu_run()?

Then you could get rid of the RSP adjustment hack, and the
vmx_update_host_rsp() function altogether.

> Is this important since kvm_spurious_fault is just BUG()?

It's probably only important if you care about the stack trace for the
BUG() case.  But BP is clobbered anyway so I guess it doesn't matter.

> There is no macro currently to support CONFIG_DEBUG_BUGVERBOSE in
> assembly code, but it's also fine if you just change the call to ud2.

That would be one way to make objtool happy.

-- 
Josh