[Xen-devel] A question on how interrupts work

["Ronald G. Minnich" <rminnich@xxxxxxxx>]

I'm wondering about something in xen I don't understand, related to 
interrupts. 

Basically, in hardware systems you have a processor running with
interrupts enabled or disabled, which in Unix and sons generally is called
a priority level, let's just call it hi or lo. In many OSes (Plan 9
included) to block interrupts you splhi, to enable them you spllo. In
Linux it is CLI to block and STI to enable.

When running at lo, you can take an interrupt and you land in the kernel
at splhi; or you can take a fault and land in the kernel without changing
to hi or lo. As a general rule, the cpu saves your state including your
interrupt enable flags (x86 does this in eflags). For page faults,
typically you run at whatever level you were at in the kernel fault
handler; for hardware interrupts typically you run at splhi, regardless of
where you were before. In the handler, you do your work and (e.g.) execute
an iret. Regardless of the level you are running at in the fault handler,
after the iret, you are running at the previous priority level, i.e. hi or
lo. So you can, for example, page fault in an interrupt routine. 

Hardware saves your interrupt-enabled flag and restores it automagically
when you execute the iret. On interrupt, the IF flag is cleared, no more
interrupts can happen. On page fault, the IF flag is not touched. In any
event, it's not the job of the interrupt handler to restore the state of
the IF flag that was in play before the interrupt or exception -- hardware
does that, specifically the IRET popping EFLAGS on the x86 restores the
IF.

My question is, why doesn't Xen work that way? In other words, Xen will 
set the mask for the event channel; but restoring it is up to the OS. If 
Xen worked the way the hardware does, Xen would save the mask, set the 
mask, and then restore the mask to its previous value when the OS returns 
from the trap. Is there a reason that the OS has to do the restoration of 
the mask? I am wondering because I just fixed a bug in Plan 9 that boiled 
down to adding an spllo() to the plan 9 trap handler, since Xen sets the 
mask on page fault and does not clear it when the OS returns. Why doesn't 
Xen do the equivalent of this:

        x = splhi();
        trap_to_os();
        splx(x);

instead of what is does now, which is pretty much this:
        splhi();
        trap_to_os();
        /* OS restores IF */

There's an awful lot of complexity in the trap handler in the OS to deal 
with the problem of the OS setting spllo() before doing the iret, since as 
soon as the OS sets spllo() it can take an interrupt -- while in the 
interrupt handler. 

thanks for any clarity you can lend to my brain :-)

ron



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel