[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset



>>> On 03.06.15 at 15:35, <vkuznets@xxxxxxxxxx> wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -274,11 +274,13 @@ static long 
> evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>  
>      lchn->u.interdomain.remote_dom  = rd;
>      lchn->u.interdomain.remote_port = rport;
> +    lchn->u.interdomain.opened_by   = current->domain;
>      lchn->state                     = ECS_INTERDOMAIN;
>      evtchn_port_init(ld, lchn);
>      
>      rchn->u.interdomain.remote_dom  = ld;
>      rchn->u.interdomain.remote_port = lport;
> +    rchn->u.interdomain.opened_by   = current->domain;
>      rchn->state                     = ECS_INTERDOMAIN;

For one ld == current->domain. And I don't think you need to store
domain pointers here; storing the domain ID would seem sufficient
(with the nice benefit of not growing struct evtchn). Plus
"opened_by" doesn't really reflect what is being done here - the
event channels are being bound, not opened.

> @@ -933,26 +935,30 @@ int evtchn_unmask(unsigned int port)
>  }
>  
>  
> -static long evtchn_reset(evtchn_reset_t *r)
> +void evtchn_reset(struct domain *d, bool_t soft_reset)
>  {
> -    domid_t dom = r->dom;
> -    struct domain *d;
> -    int i, rc;
> -
> -    d = rcu_lock_domain_by_any_id(dom);
> -    if ( d == NULL )
> -        return -ESRCH;
> -
> -    rc = xsm_evtchn_reset(XSM_TARGET, current->domain, d);
> -    if ( rc )
> -        goto out;
> +    int i;

unsigned int

> +    struct evtchn *chn;

const (and perhaps moved inside the loop below)

> +    /*
> +     * ECS_INTERDOMAIN channels with port number suitable for the 2-level ABI
> +     * opened by other domains should remain opened as the domain doing soft
> +     * reset won't be able to reopen them.

One question of course is - does this really apply to _all_ interdomain
event channels (rather than just to the xenstore and xenconsole ones)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.