public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Nikunj A Dadhania <nikunj@amd.com>,
	kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH] KVM: SVM: Add exception to disable objtool warning for kvm-amd.o
Date: Thu, 3 Aug 2023 21:07:28 +0200	[thread overview]
Message-ID: <20230803190728.GJ212435@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <b22761ea-cab6-0e11-cdc9-ec26c300cd3f@redhat.com>

On Thu, Aug 03, 2023 at 08:06:20PM +0200, Paolo Bonzini wrote:
> On 8/3/23 14:06, Peter Zijlstra wrote:
> > 
> > By marking them with STACK_FRAME_NON_STANDARD you will get no ORC data
> > at all, and then you also violate the normal framepointer calling
> > convention.
> > 
> > This means that if you need to unwind here you're up a creek without no
> > paddles on.
> 
> The only weird thing that can happen is ud2 instructions that are executed
> in case the vmload/vmrun/vmsave instructions causes a #GP, from the
> exception handler.

This code is ran with GIF disabled, so NMIs are not in the books, right?
Does GIF block #MC ?

> If I understand correctly those ud2 would use ORC information to show the
> backtrace, but even then the frame pointer should be correct.  Of these
> instructions, vmrun is the only one that runs with wrong %rbp; and it is
> unlikely or even impossible that a #GP happens at vmrun, because the same
> operand has been used for a vmload ten instructions before. The only time I
> saw that #GP it was due to a processor errata, but it happened consistently
> on the vmload.
> 
> So if frame pointer unwinding can be used in the absence of ORC, Nikunj
> patch should not break anything.

But framepointer unwinds rely on BP, and that is clobbered per the
objtool complaint.

Also, if you look at the makefile hunk that's being replaced, that was
conditional on CONFIG_FRAMEPOINTS, while the annotation that's being
added is not. I think objtool won't complain for ORC builds, only for
framepoints builds.

  reply	other threads:[~2023-08-03 19:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02  9:11 [PATCH] KVM: SVM: Add exception to disable objtool warning for kvm-amd.o Nikunj A Dadhania
2023-08-02 14:02 ` Sean Christopherson
2023-08-03  6:25   ` Nikunj A. Dadhania
2023-08-03 12:06 ` Peter Zijlstra
2023-08-03 18:06   ` Paolo Bonzini
2023-08-03 19:07     ` Peter Zijlstra [this message]
2023-08-04  3:25       ` Nikunj A. Dadhania
2023-08-04 10:20       ` Paolo Bonzini
2023-08-04 20:48         ` Peter Zijlstra
2023-08-04 23:19           ` Josh Poimboeuf
2023-08-05  0:55             ` Peter Zijlstra
2023-08-10 14:17               ` Paolo Bonzini
2023-08-10 21:14                 ` Peter Zijlstra
2023-08-04 11:14 ` Peter Zijlstra
2023-08-04 12:40   ` Nikunj A. Dadhania
2023-08-04 20:42     ` Peter Zijlstra
2023-08-12  0:51 ` kernel test robot

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=20230803190728.GJ212435@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=jpoimboe@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=ravi.bangoria@amd.com \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    /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