Re: STI, HLT in acpi_cpu_idle_c1

On Sat, 10 Jul 2004, Scott Long wrote:

> John Baldwin wrote:
> > Once the EOI is sent to the APIC, the processor will except other interrupts.
> > However, most of the interrupt code also runs with interrupts disabled.  The
> > exception is in ast(), meaning that another interrupt can come in and nest
> > during an ast(), but ast() is not called during nested returns, so it won't
> > nest infinitely.  iret doesn't do any sort of EOI magic, all it does is popf
> > followed by ret.  The popf usually enables interrupts when it restores the
> > interrupt flag's state.  It might still be a hardware problem in the chipset,
> > esp. since it always happens on a logical CPU.  The fact that no other boxes
> > in the field besides the two identical boxes you have have demonstrated this
> > problem makes me very suspicious with respect to the hardware.
> >
>
> Well, the real question is what happens in when the interrupt context
> has to contest on the proc lock in ast().  What goes to sleep, and how

This never happens, because ast() is never called in interrupt context.

> it wake up?  Does the interrupt context have a real process/thread
> associated with it, or does it pretend to be curthread, or what?  Since
> the whole point of ithreads was to allow sleep locks in interrupt
> handlers, isn't this a major violation?

ast() is only called on return to user mode.  This implies that curthread
is a user thread (the one returning to user mode).  It can never be an
ithread.  Most ast()s are on return from syscalls.  Some are on return
from interrupts, but these are best thought of as being in process context
too.  The interrupt has been completely handled (*) except for the final
return from it.  As an implementation detail, ast() is called directly
before returning.  I believe entry to ast() was originally in hardware on
VAXes.  There was a hardware instruction to schedule an additional trap
on return.  We could still do this in hardware on i386's at least by
scheduling a trace trap, but a direct call is better.  The SMP case still
needs hardware (an IPI) for non-current CPUs.

(*) Except possibly for magic and bugs.  E.g., the iret after an NMI is
special on at least some i386's, but is not handled right.

Bruce