[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, 14 Dec 2004, Keir Fraser wrote:

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

You're right, I said it incorrectly, for some reason I switched in my 
Last-1th attempt to figure out what was up with the last one. Oops.

The plan 9 trap handler assumes that there is a hardware restore of INTF, 
which is generally true of modern CPUs. 

So what was happening was that at the end of the Plan 9 trap handler there 
was an splhi for a critical section (two lines or some such) then a 
return. There was no spllo() as they relied on hardware. I just 
realized the easy way to fix this, which is to take my own medicine: 
        x = splhi();

just need to talk to the plan 9 guys about this and fix up their trap code 
if they're willing. 

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

That's what I figured. I was wondering if you all knew the tradeoff of 
adding complexity at the OS trap level vs. just dropping back to 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.

OK. I was assuming this was the reason. So the idea is that the tradeoff 
of NOT doing this:
is worth the complexity of the trap return code which I see in the various 
kernels. Has this tradeoff been measured and is known to be the one we 
want? I'm more curious than anything.

Thanks 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. 
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.