Xen devel - Jun 2004 - trying to understand interrupts from xen->guest

I''m enabling interrupts by this:
_shared->vcpu_data[0].evtchan_upcall_pending = 0;

I get an interrupt but the stack is really odd. I can''t make sense of
it.
Nothing looks like it is in the right place, though bits and pieces are 
recognizable: I can see the address for _shared, for example on the stack. 

I''m trying to find out where Xen might have invoked the interrupt but
no
luck. Plan 9 is mostly working and I want to get Xen interrupts going to 
it, but this last bit is puzzling. 

I do have the callback addresses set. 

Does xen interrupt on vector 0x82 to send interrupts to the guest? This is  
a guest in dom > 0.

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Thu, 24 Jun 2004, ron minnich wrote:
> Does xen interrupt on vector 0x82 to send interrupts to the guest? This is
> a guest in dom > 0.
hmm, more reading seems to show it comes in on irq 3, is that correct?

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> 
> I''m enabling interrupts by this:
> _shared->vcpu_data[0].evtchan_upcall_pending = 0;
I presume you actually mean ''evtchn_upcall_mask''?
> I get an interrupt but the stack is really odd. I can''t make sense
of it.
> Nothing looks like it is in the right place, though bits and pieces are 
> recognizable: I can see the address for _shared, for example on the stack. 
The interrupt stack frame is identical to that for a real x86 hardware
interrupt. i.e.: EIP, CS, EFLAGS[, ESP, SS]. No pointers to
shared_info, or anything like that.
> I''m trying to find out where Xen might have invoked the interrupt
but no
> luck. Plan 9 is mostly working and I want to get Xen interrupts going to 
> it, but this last bit is puzzling. 
> 
> I do have the callback addresses set. 
It will enter the callback address you specified via
HYPERVISOR_set_callbacks(). It has nothing to do with the ''virtual
IDT'' you specify via HYPERVISOR_set_trap_table().
> Does xen interrupt on vector 0x82 to send interrupts to the guest? This is
> a guest in dom > 0.
No. 0x82 is the trap used to enter Xen from a guest OS.

 -- Keir


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

I''m definitely getting an interrupt from xen when I disable the mask. 

Any idea why this would happen? I hvae set the callback address at this 
point. 

hmm maybe it is calling back to 0 ... that would explain my call frame 
completely. 


arg.

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> I''m definitely getting an interrupt from xen when I disable the
mask.
> 
> Any idea why this would happen? I hvae set the callback address at this 
> point. 
> 
> hmm maybe it is calling back to 0 ... that would explain my call frame 
> completely. 
Not sure what you mean here. Yes, you could get an interrupt on
event-channel 0 -- at start of day no event channels are masked, but
also none are bound to event sources. The only exception is evtchn 0,
which is statically bound to VIRQ_MISDIRECT. This is a ''dumping
ground'' for any VIRQs that occur that you have not yet bound to an
event channel.

So, you are receiving periodic ticks on VIRQ_TIMER. These aren''t
bouind to an event channel, so they get passed to VIRQ_MISDIRECT which
is bound to evtchn0. This causes the pend flag to get set for your
domain, and so you get an interrupt next time you disable the mask.

Of course, you don''t get the interrupt immediately. :-) You get it
next time Xen is invoked and then returns to you. If you want to
process outstanding events sooner then you need to manually check the
pending flag and take appropriate action. This is what I do in Linux''s
''enable_local_irq()'' function, for example.

 -- Keir


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 25 Jun 2004, Keir Fraser wrote:
> > hmm maybe it is calling back to 0 ... that would explain my call frame
> > completely. 
> 
> Not sure what you mean here. Yes, you could get an interrupt on
> event-channel 0 -- at start of day no event channels are masked, but
> also none are bound to event sources. The only exception is evtchn 0,
> which is statically bound to VIRQ_MISDIRECT. This is a ''dumping
> ground'' for any VIRQs that occur that you have not yet bound to an
> event channel.
no, what I mean is, I get a trap which to plan 9 exception handlers 
looks like a page fault and the PC is 0. This could be the variable-sized 
xen stack frame confusing plan 9 trap again, however.

I am worried that xen is calling back to that PC somehow. Seems unlikely 
but it would explain the stack frame I have. 

HOWEVER  ... seems that what you are telling me is that I should expect an 
irq on VIRQ_MISDIRECT, which makes a lot of sense and explains the linux 
code I see. 

So I''ll look at that too. 

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 25 Jun 2004, ron minnich wrote:
> HOWEVER  ... seems that what you are telling me is that I should expect an 
> irq on VIRQ_MISDIRECT, which makes a lot of sense and explains the linux 
> code I see. 
ah, of course, that vector is not set up and so of course I''ll get a
trap.
DUH.

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel