Xen devel - Nov 2006 - [PATCH] Allow mini-os to unbind all evtchns

The attached patch exports a function clients can call to have all Xen
ports unbound. This is necessary when using mini-os as the foundation
for a boot-loader.

Regards,
Jacob


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

On Fri, 2006-11-24 at 13:27 +0100, Jacob Gorm Hansen
wrote:
> The attached patch exports a function clients can call to have all Xen
> ports unbound. This is necessary when using mini-os as the foundation
> for a boot-loader.
Sorry, that patch did not work as intended. The correct version is
attached. Bound ports are tracked in an array, and a function to unbind
all ports in the array is exported.

Jacob


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

The patch looks good to me. I only have one comment: it would be good  
to have unbind_all_ports in the events header file.

Cheers
Gregor
On 28 Nov 2006, at 12:06, Jacob Gorm Hansen wrote:
> On Fri, 2006-11-24 at 13:27 +0100, Jacob Gorm Hansen wrote:
>> The attached patch exports a function clients can call to have all  
>> Xen
>> ports unbound. This is necessary when using mini-os as the foundation
>> for a boot-loader.
>
> Sorry, that patch did not work as intended. The correct version is
> attached. Bound ports are tracked in an array, and a function to  
> unbind
> all ports in the array is exported.
>
> Jacob
> <miniosunbindall.patch>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

On 29/11/06 12:16, "Grzegorz Milos" <gm281@cam.ac.uk> wrote:
> The patch looks good to me. I only have one comment: it would be good
> to have unbind_all_ports in the events header file.
It looked bogus to me. What if event channels are bound/unbound/bound
multiple times during the mini-os lifetime (can''t happen right now, but
maybe in future). The port array will overflow. Perhaps it should be a
bitmap instead (set on bind; clear on unbind)?

 -- Keir


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

Am Mittwoch, 29. November 2006 13:25 schrieb Keir
Fraser:
> ...
> It looked bogus to me. What if event channels are bound/unbound/bound
> multiple times during the mini-os lifetime (can''t happen right
now, but
> maybe in future). The port array will overflow. Perhaps it should be a
What does it means "maybe in future"?
Has it to do with:
> On Fri, 2006-11-24 at 13:27 +0100, Jacob Gorm Hansen wrote:
>> ...
>> ports unbound. This is necessary when using mini-os as the foundation
>> for a boot-loader.
Can anybody give me a hint!
Thanks.

Dietmar.

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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Dietmar Hahn
> Sent: 29 November 2006 13:27
> To: xen-devel@lists.xensource.com
> Cc: Jacob Gorm Hansen; Keir Fraser; Grzegorz Milos
> Subject: Re: [Xen-devel] [PATCH] Allow mini-os to unbind all evtchns
> 
> Am Mittwoch, 29. November 2006 13:25 schrieb Keir Fraser:
> > ...
> > It looked bogus to me. What if event channels are 
> bound/unbound/bound
> > multiple times during the mini-os lifetime (can''t happen 
> right now, but
> > maybe in future). The port array will overflow. Perhaps it 
> should be a
> What does it means "maybe in future"?
> Has it to do with:
> > On Fri, 2006-11-24 at 13:27 +0100, Jacob Gorm Hansen wrote:
> >> ...
> >> ports unbound. This is necessary when using mini-os as the 
> foundation
> >> for a boot-loader.
> Can anybody give me a hint!
I''m not sure that is what Keir meant - more like: If you implement
something, you may just as well think about any future extended features
if it doesn''t cause too much problems, for example using a bitmap
instead of a plain array. 

Another solution in this case would be to search/clear the array so that
multiple bind/unbind operations don''t cause the array content to
"grow".


--
Mats
> Thanks.
> 
> Dietmar.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 


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

> I''m not sure that is what Keir meant - more like: If you implement
> something, you may just as well think about any future extended features
> if it doesn''t cause too much problems, for example using a bitmap
> instead of a plain array.
>
> Another solution in this case would be to search/clear the array so that
> multiple bind/unbind operations don''t cause the array content to
"grow".
>
>
> --
> Mats
OK, I thought that maybe mini-os should play a special role in the future and 
there are special aims with it ;-).
Thanks.

Dietmar

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

I guess bitmap would work better. We won''t have to rewrite the code  
once event channel unbounding is allowed... Shouldn''t be too hard.

Thanks
Gregor

On 29 Nov 2006, at 12:25, Keir Fraser wrote:
> On 29/11/06 12:16, "Grzegorz Milos" <gm281@cam.ac.uk>
wrote:
>
>> The patch looks good to me. I only have one comment: it would be good
>> to have unbind_all_ports in the events header file.
>
> It looked bogus to me. What if event channels are bound/unbound/bound
> multiple times during the mini-os lifetime (can''t happen right
now,
> but
> maybe in future). The port array will overflow. Perhaps it should be a
> bitmap instead (set on bind; clear on unbind)?
>
>  -- Keir

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

On Wed, 2006-11-29 at 12:25 +0000, Keir Fraser wrote:
> On 29/11/06 12:16, "Grzegorz Milos" <gm281@cam.ac.uk>
wrote:
> 
> > The patch looks good to me. I only have one comment: it would be good
> > to have unbind_all_ports in the events header file.
> 
> It looked bogus to me. What if event channels are bound/unbound/bound
> multiple times during the mini-os lifetime (can''t happen right
now, but
> maybe in future). The port array will overflow. Perhaps it should be a
> bitmap instead (set on bind; clear on unbind)?
I have attached a new version that uses a bitmap instead and declares
unbind_all_ports() in events.h.

regards,
Jacob


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

I''ve reworked the patch a little bit. I''ve added
"flags" field to
ev_action_t instead of creating a separate bitmap. The basic idea is 
still the some though.

This patch makes sure that all the ports are marked unbound on init, 
which your patch failed to do.

We can merge flags and count fields together, if we care about the space 
wasted.

Cheers
Gregor

(Keir could you apply please?)

Jacob Gorm Hansen wrote:
> On Wed, 2006-11-29 at 12:25 +0000, Keir Fraser wrote:
>> On 29/11/06 12:16, "Grzegorz Milos" <gm281@cam.ac.uk>
wrote:
>>
>>> The patch looks good to me. I only have one comment: it would be
good
>>> to have unbind_all_ports in the events header file.
>> It looked bogus to me. What if event channels are bound/unbound/bound
>> multiple times during the mini-os lifetime (can''t happen right
now, but
>> maybe in future). The port array will overflow. Perhaps it should be a
>> bitmap instead (set on bind; clear on unbind)?
> 
> I have attached a new version that uses a bitmap instead and declares
> unbind_all_ports() in events.h.
> 
> regards,
> Jacob
> 
> 
> ------------------------------------------------------------------------
> 
> Signed-off-by: Jacob Gorm Hansen <jacobg@diku.dk>
> 
> diff -r 52ae8dd4bc75 extras/mini-os/events.c
> --- a/extras/mini-os/events.c	Tue Oct 17 22:09:52 2006 +0100
> +++ b/extras/mini-os/events.c	Thu Nov 30 17:34:29 2006 +0100
> @@ -31,10 +31,26 @@ typedef struct _ev_action_t {
>      u32 count;
>  } ev_action_t;
>  
> +unsigned long bound_ports[NR_EVS/(8*sizeof(unsigned long))];
>  
>  static ev_action_t ev_actions[NR_EVS];
>  void default_handler(evtchn_port_t port, struct pt_regs *regs, void
*data);
>  
> +void unbind_all_ports(void)
> +{
> +    int i;
> +
> +    for(i=0; i<NR_EVS; i++)
> +    {
> +        if(test_and_clear_bit(i,bound_ports))
> +        {
> +            struct evtchn_close close;
> +            mask_evtchn(i);
> +            close.port = i;
> +            HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
> +        }
> +    }
> +}
>  
>  /*
>   * Demux events to different handlers.
> @@ -99,6 +115,7 @@ int bind_virq(uint32_t virq, evtchn_hand
>  		printk("Failed to bind virtual IRQ %d\n", virq);
>  		return 1;
>      }
> +    set_bit(op.port,bound_ports);
>      bind_evtchn(op.port, handler, data);
>  	return 0;
>  }
> @@ -173,6 +190,7 @@ int evtchn_bind_interdomain(domid_t pal,
>      int err = HYPERVISOR_event_channel_op(EVTCHNOP_bind_interdomain,
&op);
>      if (err)
>  		return err;
> +    set_bit(op.local_port,bound_ports);
>  	evtchn_port_t port = op.local_port;
>      clear_evtchn(port);	      /* Without, handler gets invoked now! */
>      *local_port = bind_evtchn(port, handler, data);
> diff -r 52ae8dd4bc75 extras/mini-os/include/events.h
> --- a/extras/mini-os/include/events.h	Tue Oct 17 22:09:52 2006 +0100
> +++ b/extras/mini-os/include/events.h	Thu Nov 30 17:34:29 2006 +0100
> @@ -36,6 +36,7 @@ int evtchn_bind_interdomain(domid_t pal,
>  int evtchn_bind_interdomain(domid_t pal, evtchn_port_t remote_port,
>  							evtchn_handler_t handler, void *data,
>  							evtchn_port_t *local_port);
> +void unbind_all_ports(void);
>  
>  static inline int notify_remote_via_evtchn(evtchn_port_t port)
>  {

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