From: Avi Kivity <avi@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: x86@kernel.org, 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 16:17:15 +0200 [thread overview]
Message-ID: <4CA0A76B.6000803@redhat.com> (raw)
In-Reply-To: <20100927103128.GO15338@8bytes.org>
On 09/27/2010 12:31 PM, Joerg Roedel wrote:
> On Sun, Sep 19, 2010 at 06:28:19PM +0200, 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).
>
> Doesn't the interrupt return path check for a re-schedule condition
> before iret? So to my believe the handler would not jump back to the
> idle task if something else becomes running in the interrupt handler,
> no?
>
Perhaps on preemptible kernels? But at least on non-preemptible
kernels, you can't just switch tasks while running kernel code.
void cpu_idle(void)
{
current_thread_info()->status |= TS_POLLING;
/*
* If we're the non-boot CPU, nothing set the stack canary up
* for us. CPU0 already has it initialized but no harm in
* doing it again. This is a good place for updating it, as
* we wont ever return from this function (so the invalid
* canaries already on the stack wont ever trigger).
*/
boot_init_stack_canary();
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick(1);
while (!need_resched()) {
rmb();
if (cpu_is_offline(smp_processor_id()))
play_dead();
/*
* Idle routines should keep interrupts disabled
* from here on, until they go to idle.
* Otherwise, idle callbacks can misfire.
*/
local_irq_disable();
enter_idle();
/* Don't trace irqs off for idle */
stop_critical_timings();
pm_idle();
start_critical_timings();
trace_power_end(smp_processor_id());
/* In many cases the interrupt that ended idle
has already called exit_idle. But some idle
loops can be woken up without interrupt. */
__exit_idle();
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
schedule();
preempt_disable();
}
}
Looks like we rely on an explicit schedule() - pm_idle() is called with
preemption disabled.
(pm_idle eventually calls safe_halt() if no other idle method is used)
--
error compiling committee.c: too many arguments to function
prev parent reply other threads:[~2010-09-27 14:17 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
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 [this message]
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=4CA0A76B.6000803@redhat.com \
--to=avi@redhat.com \
--cc=joro@8bytes.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.