From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Uros Bizjak <ubizjak@gmail.com>, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/2] KVM: VMX: Move IRQ invocation to assembly subroutine
Date: Mon, 14 Sep 2020 16:38:13 -0500 [thread overview]
Message-ID: <20200914213813.zfxlffphcp5czvof@treble> (raw)
In-Reply-To: <20200914210719.GB7084@sjchrist-ice>
On Mon, Sep 14, 2020 at 02:07:19PM -0700, Sean Christopherson wrote:
> > RSP needs to be aligned to what? How would this align the stack, other
> > than by accident?
>
> Ah, yeah, that's lacking info.
>
> 16-byte aligned to correctly mimic CPU behavior when vectoring an IRQ/NMI.
> When not changing stack, the CPU aligns RSP before pushing the frame.
>
> The above shenanigans work because the x86-64 ABI also requires RSP to be
> 16-byte aligned prior to CALL. RSP is thus 8-byte aligned due to CALL
> pushing the return IP, and so creating the stack frame by pushing RBP makes
> it 16-byte aliagned again.
As Uros mentioned, the kernel doesn't do this.
> > > +
> > > +#ifdef CONFIG_X86_64
> > > + push $__KERNEL_DS
> > > + push %_ASM_BP
> > > +#endif
> > > + pushf
> > > + push $__KERNEL_CS
> > > + CALL_NOSPEC _ASM_ARG1
> > > +
> > > + /*
> > > + * "Restore" RSP from RBP, even though IRET has already unwound RSP to
> > > + * the correct value. objtool doesn't know the target will IRET and so
> > > + * thinks the stack is getting walloped (without the explicit restore).
> > > + */
> > > + mov %_ASM_BP, %rsp
> > > + pop %_ASM_BP
> > > + ret
> >
> > BTW, there *is* actually an unwind hint for this situation:
> > UNWIND_HINT_RET_OFFSET.
>
> I played with that one, but for the life of me couldn't figure out how to
> satisfy both the "stack size" and "cfa.offset" checks. In the code below,
> cfa.offset will be 8, stack_size will be 40 and initial_func_cfi.cfa.offset
> will be 8. But rereading this, I assume I missed something that would allow
> maniuplating cfa.offset? Or maybe I botched my debugging?
>
> static bool has_modified_stack_frame(struct instruction *insn, struct insn_state *state)
> {
> ...
>
> if (cfi->cfa.offset != initial_func_cfi.cfa.offset + ret_offset)
> return true;
>
> if (cfi->stack_size != initial_func_cfi.cfa.offset + ret_offset)
> return true;
>
> ...
> }
It only works without the frame pointer, in which case stack size and
cfa.offset will be the same (see below code). With the frame pointer,
it probably wouldn't work.
But if you're going to be aligning the stack in the next patch version,
your frame pointer approach works better anyway, because the stack size
will be variable depending on the stack alignment of the callee. So
forget I said anything :-)
> > So you might be able to do something like the following (depending on
> > what your alignment requirements actually are):
> >
> > SYM_FUNC_START(vmx_do_interrupt_nmi_irqoff)
> > #ifdef CONFIG_X86_64
> > push $__KERNEL_DS
> > push %_ASM_BP
> > #endif
> > pushf
> > push $__KERNEL_CS
> > CALL_NOSPEC _ASM_ARG1
> >
> > /* The call popped the pushes */
> > UNWIND_HINT_RET_OFFSET sp_offset=32
> >
> > ret
> > SYM_FUNC_END(vmx_do_interrupt_nmi_irqoff)
--
Josh
next prev parent reply other threads:[~2020-09-14 21:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 19:56 [PATCH 0/2] KVM: VMX: Clean up IRQ/NMI handling Sean Christopherson
2020-09-14 19:56 ` [PATCH 2/2] KVM: VMX: Invoke NMI handler via indirect call instead of INTn Sean Christopherson
[not found] ` <20200914195634.12881-2-sean.j.christopherson@intel.com>
2020-09-14 20:37 ` [PATCH 1/2] KVM: VMX: Move IRQ invocation to assembly subroutine Uros Bizjak
2020-09-14 21:08 ` Sean Christopherson
2020-09-14 20:40 ` Josh Poimboeuf
[not found] ` <20200914210719.GB7084@sjchrist-ice>
2020-09-14 21:21 ` Uros Bizjak
2020-09-14 21:31 ` Uros Bizjak
2020-09-14 21:55 ` Sean Christopherson
2020-09-14 21:38 ` Josh Poimboeuf [this message]
2020-09-14 21:54 ` Sean Christopherson
2020-09-15 2:42 ` Andi Kleen
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=20200914213813.zfxlffphcp5czvof@treble \
--to=jpoimboe@redhat.com \
--cc=ak@linux.intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=ubizjak@gmail.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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