On Tue, Jan 15, 2019 at 08:13:22AM +0100, Paolo Bonzini wrote:
> On 15/01/19 08:04, Qian Cai wrote:
> >
> >
> > On 1/15/19 1:44 AM, Qian Cai wrote:
> >> compilation warning since v5.0-rc1,
> >>
> >> arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_run.part.17()+0x3171:
> >> call without frame pointer save/setup
The warning is complaining about vmx_vcpu_run() in vmx.c, not vmenter.S.
The rule being "broken" is that a call is made without creating a stack
frame, and vmx_vmenter() obviously makes no calls.
E.g., manually running objtool check:
$ tools/objtool/objtool check arch/x86/kvm/vmx/vmenter.o
$ tools/objtool/objtool check arch/x86/kvm/vmx/vmx.o
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_run.part.19()+0x83e:
call without frame pointer save/setup
I put "broken" in quotes because AFAICT we're not actually violating the
rule. From tools/objtool/Documentation/stack-validation.txt:
If it's a GCC-compiled .c file, the error may be because the function
uses an inline asm() statement which has a "call" instruction. An
asm() statement with a call instruction must declare the use of the
stack pointer in its output operand. On x86_64, this means adding
the ASM_CALL_CONSTRAINT as an output constraint:
asm volatile("call func" : ASM_CALL_CONSTRAINT);
Otherwise the stack frame may not get created before the call.
The asm() blob that calls vmx_vmenter() uses ASM_CALL_CONSTRAINT, and
the resulting asm output generates a frame pointer, e.g. this is from
the vmx.o that objtool warns on:
Dump of assembler code for function vmx_vcpu_run:
0x0000000000007440 <+0>: e8 00 00 00 00 callq 0x7445 <vmx_vcpu_run+5>
0x0000000000007445 <+5>: 55 push %rbp
0x0000000000007446 <+6>: 48 89 e5 mov %rsp,%rbp
The warning only shows up in certain configs, e.g. I was only able to
reproduce this using the .config provided by lkp. Even explicitly
enabling CONFIG_FRAME_POINTERS and CONFIG_STACK_VALIDATION didn't
trigger the warning using my usual config.
And all that being said, I'm pretty sure this isn't related to the call
to vmx_vmenter() at all, but rather is something that was exposed by
removing __noclone from vmx_vcpu_run().
E.g. I still get the warning if I comment out the call to vmx_vmenter,
it just shifts to something else (and continues to shift I comment out
more calls). The warning goes away if I re-add __noclone, regardless
of whether or not commit 2bcbd406715d ("Revert "compiler-gcc: disable
-ftracer for __noclone functions"") is applied.
0x6659 is in vmx_vcpu_run (./arch/x86/include/asm/spec-ctrl.h:43).
38 * Avoids writing to the MSR if the content/bits are the same
39 */
40 static inline
41 void x86_spec_ctrl_restore_host(u64 guest_spec_ctrl, u64
guest_virt_spec_ctrl)
42 {
43 x86_virt_spec_ctrl(guest_spec_ctrl, guest_virt_spec_ctrl,
false);
44 }
45
46 /* AMD specific Speculative Store Bypass MSR data */
47 extern u64 x86_amd_ls_cfg_base;
What's really baffling is that we explicitly tell objtool to not do stack
metadata validation on vmx_vcpu_run():
STACK_FRAME_NON_STANDARD(vmx_vcpu_run);
As an aside, we might be able to remove STACK_FRAME_NON_STANDARD, assuming
we get this warning sorted out.
> >> Fixes: 453eafbe65f (KVM: VMX: Move VM-Enter + VM-Exit handling to
> >> non-inline sub-routines)
> >
> > Oops, wrong fix. Back to square one.
> >
>
> Hmm, maybe like this:
>
> diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S
> index bcef2c7e9bc4..33122fa9d4bd 100644
> --- a/arch/x86/kvm/vmx/vmenter.S
> +++ b/arch/x86/kvm/vmx/vmenter.S
> @@ -26,19 +26,17 @@ ENTRY(vmx_vmenter)
> ret
>
> 2: vmlaunch
> +3:
> ret
>
> -3: cmpb $0, kvm_rebooting
> - jne 4f
> - call kvm_spurious_fault
> -4: ret
> -
> .pushsection .fixup, "ax"
> -5: jmp 3b
> +4: cmpb $0, kvm_rebooting
> + jne 3b
> + jmp kvm_spurious_fault
> .popsection
>
> - _ASM_EXTABLE(1b, 5b)
> - _ASM_EXTABLE(2b, 5b)
> + _ASM_EXTABLE(1b, 4b)
> + _ASM_EXTABLE(2b, 4b)
>
> ENDPROC(vmx_vmenter)
>
>
> Paolo
