WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] SCHEDOP_block_masked

On Fri, Mar 10, 2006 at 01:21:39PM +0000, Keir Fraser wrote:

> >But, now you mention it, I wonder if this wouldn't be better taking an
> >event channel to check on before sleeping (though we'd still wake on
> >any). This would avoid the small race (which doesn't really matter in
> >the context we've been using this).
> 
> Can you give more details about the usage scenario?

The debugger is calling out to the xen console driver getchar() routine.
Currently it's doing something like:

        if (!check_for_xencons_char)
                HYPERVISOR_yield();

Thus as soon as we see something on the console ring buffer we can
continue on (still inside the kernel debugger). Events must remain
disabled during this entire operation. With HYPERVISOR_block_on(), this
would look something like:

        clear_evtchn_pending(xencons_evtchn);

        if (check_for_xencons_char)
                break;

        HYPERVISOR_block_on(xencons_evtchn);

Xen would check for that particular evtchn before blocking the vcpu; any
event delivery would wake up the vcpu again and return to the guest
domain.

The clearing of the pending bit each time is obviously needed to stop
block_on() from waking immediately again (and this implies that the
domain needs some other way of checking for the event delivery, as
above).

Does that clear things up a little?

regards,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel