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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox