Re: [Xen-devel] [PATCH] Mini-OS update of events initialisation

[Melvin Anderson <Melvin.Anderson@xxxxxx>]

On Fri, 2006-11-17 at 15:29 +0000, Grzegorz Milos wrote:
> > Suppose a callback occurs between the calls of __sti() and
> > init_events().  The function do_event() calls the handler indirectly via
> > the array ev_actions.  But ev_actions is initialised in init_events(),
> > so if do_event() is called too early, the function pointer "handler" in
> > ev_actions will still be 0 (default for static storage).  We start again
> > at virtual address 0, which is the entry point of Mini-OS, but %esi will
> > not now point to the start_info page.  I think this explains why Mini-OS
> > sometimes gets "restarted", and when it does the start_info page seems
> > to be garbage.
> 
> This seems to explain the "restart". However, my understanding was that 
>   an event port has to be explicitly unmasked in order for any event to 
> be delivered (i.e. that all event ports are masked by default). 
> Unmasking is done by bind_evtchn() or bind_virq() in event.s. All calls 
> to these functions happen after init_events() (in init_time(), 
> init_console() and init_xenbus()). I guess the best way to verify if 
> your scenario is correct is to put 'printk' in do_events(). Could you 
> try this Melvin?

Very good question.  I have just tried calling a modified version of
init_events() to set up the default_handler before __sti() is called,
but my modified init_events() did not call mask_evtchn().

I find that I occasionally see an event on port 2.  Looking at the debug
output from xend (I ran xend with XEND_DEBUG=1 set in the environment),
I see that this is the console event port.

I have just looked at the domain builder code in libxc,
tools/libxc/xc_linux_build.c, function setup_guest().  I see that this
initialises the shared_info page with:

    memset(shared_info, 0, PAGE_SIZE);
    /* Mask all upcalls... */
    for ( i = 0; i < MAX_VIRT_CPUS; i++ )
        shared_info->vcpu_info[i].evtchn_upcall_mask = 1;

So, the evtchn_mask array is cleared (unmasked) by the memset() call,
but the per-cpu evtchn_upcall_mask is set to hold off callbacks until we
are properly initialised.  Function __sti() clears evtchn_upcall_mask,
and as evtchn_mask array is cleared by default, that explains why the
upcall on port 2 is not masked.

Regards,

Melvin Anderson.



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