Re: [Xen-devel] fooey. no interrupts.

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> On Tue, 10 Aug 2004, Keir Fraser wrote:
> 
> > 
> > > >  4. The original value of vcpu_data[0].evtchn_upcall_pending must be 
> > > > zero.
> > > >  5. The value of vcpu_data[0].evtchn_upcall_mask must be zero.
> > > 
> > > OK, this I don't totally see. From the code I posted before, it seems to 
> > > me only the first three conditions matter. 
> > 
> > The first three conditions cause us to decide whether or not to
> > schedule the target domain, sending a cross-cpu interrupt if
> > necessary. The final two are checks just before calling back to the
> > guest OS, just to check whether it is in a position to receive async
> > callbacks. 
> 
> Keir, I don't see that in the code and Christian sent a note that left me 
> thinking it does not work that way. 
> 
> as Christian said, (4) doesn't do anything conditional, it does this:
>         /* The VCPU pending flag must be set /after/ update to 
> evtchn-pend. */
>         s->vcpu_data[0].evtchn_upcall_pending = 1;
>         guest_async_callback(d);
> 
> which looks pretty unconditional to me. Is there something else I'm 
> missing?

No, I'd forgotten how the code worked -- Christian is correct.
evtchn_upcall_pending is set unconditionally on the CPU that is
transmitting the event. evtchn_upcall_mask is only checked immediately
before return to your guest OS to determine whether or not to create
an async callback frame.

 -- Keir


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel