From: Avi Kivity <avi@redhat.com>
To: x86@kernel.org
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] x86, nmi: workaround sti; hlt race vs nmi; intr
Date: Mon, 27 Sep 2010 10:38:02 +0200 [thread overview]
Message-ID: <4CA057EA.7000609@redhat.com> (raw)
In-Reply-To: <1284913699-14986-1-git-send-email-avi@redhat.com>
On 09/19/2010 06:28 PM, Avi Kivity wrote:
> On machines without monitor/mwait we use an sti; hlt sequence to atomically
> enable interrupts and put the cpu to sleep. The sequence uses the "interrupt
> shadow" property of the sti instruction: interrupts are enabled only after
> the instruction following sti has been executed. This means an interrupt
> cannot happen in the middle of the sequence, which would leave us with
> the interrupt processed but the cpu halted.
>
> The interrupt shadow, however, can be broken by an nmi; the following
> sequence
>
> sti
> nmi ... iret
> # interrupt shadow disabled
> intr ... iret
> hlt
>
> puts the cpu to sleep, even though the interrupt may need additional processing
> after the hlt (like scheduling a task).
>
> sti is explicitly documented not to force an interrupt shadow; though many
> processors do inhibit nmi immediately after sti.
>
> Avoid the race by checking, during an nmi, if we hit the safe halt sequence.
> If we did, increment the instruction pointer past the hlt instruction; this
> allows an immediately following interrupt to return to a safe place.
>
> Signed-off-by: Avi Kivity<avi@redhat.com>
Ping.
> ---
> arch/x86/include/asm/irqflags.h | 18 +++++++++++++++++-
> arch/x86/kernel/traps.c | 14 ++++++++++++++
> 2 files changed, 31 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index 9e2b952..f412167 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -44,9 +44,25 @@ static inline void native_irq_enable(void)
> asm volatile("sti": : :"memory");
> }
>
> +extern void safe_halt_addr(void);
> +
> static inline void native_safe_halt(void)
> {
> - asm volatile("sti; hlt": : :"memory");
> + asm volatile("sti \n\t"
> + /*
> + * If NMI hits us here, it negates the interrupt shadow
> + * induced by STI. So the NMI handler checks for
> + * safe_halt_addr and skips the hlt if it loses the
> + * interrupt shadow.
> + *
> + * If native_safe_halt() is ever instantiated more
> + * than once, this will fail to build, and we'll need
> + * a list of addresses in a special section.
> + */
> + ".globl safe_halt_addr \n\t"
> + "safe_halt_addr: \n\t"
> + "hlt"
> + : : :"memory");
> }
>
> static inline void native_halt(void)
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 60788de..f67da48 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -438,6 +438,20 @@ do_nmi(struct pt_regs *regs, long error_code)
>
> inc_irq_stat(__nmi_count);
>
> + /*
> + * We hit in the middle of an sti; hlt instruction. When we return,
> + * the interrupt shadow cast by sti will no longer be in effect; then,
> + * if an interrupt causes a wakeup, we won't notice it since the hlt
> + * will take effect and block the cpu.
> + *
> + * If we detect this situation, fix it by advancing the instruction
> + * pointer past the hlt instruction; if the interrupt doesn't happen,
> + * we'll spend a few cycles falling asleep again, but that's better
> + * than a missed wakeup.
> + */
> + if (regs->cs == __KERNEL_CS&& regs->ip == (ulong)safe_halt_addr)
> + ++regs->ip;
> +
> if (!ignore_nmis)
> default_do_nmi(regs);
>
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-09-27 8:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-19 16:28 [PATCH] x86, nmi: workaround sti; hlt race vs nmi; intr Avi Kivity
2010-09-27 8:38 ` Avi Kivity [this message]
2010-09-27 9:13 ` Alexander Graf
2010-09-27 9:15 ` Alexander Graf
2010-09-27 9:17 ` Avi Kivity
2010-09-27 9:22 ` Alexander Graf
2010-09-27 9:27 ` Avi Kivity
2010-09-27 9:36 ` Alexander Graf
2010-09-27 21:55 ` H. Peter Anvin
2010-09-28 8:50 ` Avi Kivity
2010-09-28 9:22 ` Roedel, Joerg
2010-09-28 15:34 ` H. Peter Anvin
2010-09-28 16:30 ` Avi Kivity
2010-09-27 10:31 ` Joerg Roedel
2010-09-27 14:17 ` Avi Kivity
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=4CA057EA.7000609@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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