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

[Melvin Anderson <Melvin.Anderson@xxxxxx>]

We have been seeing the same problem with a 32bit Mini-OS guest.

I suspect the problem is in the initialisation order.  Looking at
start_kernel() in kernel.c:

    arch_init(si);

    trap_init();

    /* ENABLE EVENT DELIVERY. This is disabled at start of day. */
    __sti();
    
    <code omitted...>

    /* Set up events. */
    init_events();

The function arch_init() registers hypervisor_callback, and __sti()
enables events to be delivered.  Entry point hypervisor_callback is in
the assembly code in x86_32.S which calls do_hypervisor_callback() in
hypervisor.c, which in turn calls do_event() in events.c.

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.

I am not convinced that Grzegorz' patch closes the window of opportunity
for a misplaced callback, but it does reduce it.  Shouldn't __sti() be
after init_events(), not before it?

Thanks are due to Micha Moffie, who came up with key insights.

Regards,

Melvin Anderson.



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