From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Qian Cai <cai@lca.pw>, Paolo Bonzini <pbonzini@redhat.com>,
rkrcmar@redhat.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kvm: add proper frame pointer logic for vmx
Date: Tue, 15 Jan 2019 16:38:49 -0600 [thread overview]
Message-ID: <20190115223849.apk6tcbl7f7kd5d4@treble> (raw)
In-Reply-To: <20190115190617.GD21622@linux.intel.com>
On Tue, Jan 15, 2019 at 11:06:17AM -0800, Sean Christopherson wrote:
> > I can see there are five options to solve it.
> >
> > 1) always inline vmx_vcpu_run()
> > 2) always noinline vmx_vcpu_run()
> > 3) add -fdiable-ipa-fnsplit option to Makefile for vmx.o
> > 4) let STACK_FRAME_NON_STANDARD support part.* syntax.
> > 5) trim-down vmx_vcpu_run() even more to not causing splitting by GCC.
> >
> > Option 1) and 2) seems give away the decision for user with
> > CONFIG_CC_OPTIMIZE_FOR_(PERFORMANCE/SIZE).
> >
> > Option 3) prevents other functions there for splitting for optimization.
> >
> > Option 4) and 5) seems tricky to implement.
> >
> > I am not more leaning to 3) as only other fuction will miss splitting is
> > vmx_segment_access_rights().
>
> Option 4) is the most correct, but "tricky" is an understatement. Unless
> Josh is willing to pick up the task it'll likely have to wait.
>
> There's actually a few more options:
>
> 6) Replace "pop %rbp" in the vmx_vmenter() asm blob with an open-coded
> equivalent, e.g. "mov [%rsp], %rbp; add $8, %rsp". This runs an end-
> around on objtool since objtool explicitly keys off "pop %rbp" and NOT
> "mov ..., %rbp" (which is probably an objtool checking flaw?").
>
> 7) Move the vmx_vmenter() asm blob and a few other lines of code into a
> separate helper, e.g. __vmx_vcpu_run(), and mark that as having a
> non-standard stack frame.
Do you mean moving the asm blob to a .S file instead of inline asm? If
so, I think that's definitely a good idea. It would be a nice cleanup,
regardless of the objtool false positive.
That would allow vmx_vcpu_run() to be a "normal" C function which
objtool can validate (and also create ORC data for). It would also
prevent future nasty GCC optimizations (which was why the __noclone was
needed in the first place).
And also, I *think* objtool would no longer warn in that case, because
there would no longer be any calls in the function after popping %rbp.
Though if I'm wrong about that, I'd be glad to help fix the warning one
way or another.
--
Josh
next prev parent reply other threads:[~2019-01-15 22:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 6:44 Qian Cai
2019-01-15 7:04 ` Qian Cai
2019-01-15 7:13 ` Paolo Bonzini
2019-01-15 16:34 ` Sean Christopherson
2019-01-15 16:54 ` Qian Cai
2019-01-15 16:43 ` Qian Cai
2019-01-15 17:31 ` Qian Cai
2019-01-15 17:48 ` Sean Christopherson
2019-01-15 17:49 ` Sean Christopherson
2019-01-15 18:29 ` Qian Cai
2019-01-15 19:06 ` Sean Christopherson
2019-01-15 19:08 ` Sean Christopherson
2019-01-15 22:38 ` Josh Poimboeuf [this message]
2019-01-16 0:54 ` Sean Christopherson
2019-01-16 14:56 ` Josh Poimboeuf
2019-01-16 16:35 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190115223849.apk6tcbl7f7kd5d4@treble \
--to=jpoimboe@redhat.com \
--cc=bp@alien8.de \
--cc=cai@lca.pw \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®