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] Mini-OS update of events initialisation

To: Grzegorz Milos <gm281@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Mini-OS update of events initialisation
From: Melvin Anderson <Melvin.Anderson@xxxxxx>
Date: Fri, 17 Nov 2006 17:31:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Micha Moffie <micha.moffie@xxxxxx>
Delivery-date: Mon, 20 Nov 2006 01:37:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <455DD548.1010800@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: HP Labs, Bristol
References: <1163771589.2508.8.camel@xxxxxxxxxxxxxxxxxxxxxxx> <455DD548.1010800@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>