Re: [Xen-devel] A question on how interrupts work

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> 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.

This isn't true. Xen only sets the mask when it delivers an
event-channel notification. It doesn't set the mask for page faults
unless you specified a "virtual interrupt gate" instead of a "virtual
trap gate" during the set_trap_table() hypercall -- that is, for
exception vector 14 you must have set bit 2 of the flag byte of the
trap_info_t struct.

> 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. 

It avoids the need to reenter Xen to do tail work. Instead the OS does
it (with some added complexity, not on the fast path) and avoids
reentering ring 0.

Thus, in the extremely common case, an interrupt will cause ring
transitions 3->0->1->3, instead of 3->0->1->0->3.

For people who don't care about the extra cost, we could provide a
"virtual IRET" hypercall which would "atomically" reenable events and
IRET. 

 -- Keir


-------------------------------------------------------
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