Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-17 Thread Jan Beulich
>>> On 16.06.15 at 18:39, wrote: > On 16/06/15 17:19, Jan Beulich wrote: > On 16.06.15 at 17:58, wrote: >>> On 16/06/15 16:19, David Vrabel wrote: >> @@ -1221,6 +1277,8 @@ void notify_via_xen_event_channel(struct domain >> *ld, >>> int lport) >> evtchn_port_set_pending(

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread David Vrabel
On 16/06/15 17:19, Jan Beulich wrote: On 16.06.15 at 17:58, wrote: >> On 16/06/15 16:19, David Vrabel wrote: > @@ -1221,6 +1277,8 @@ void notify_via_xen_event_channel(struct domain > *ld, >> int lport) > evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); >

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread Jan Beulich
>>> On 16.06.15 at 17:58, wrote: > On 16/06/15 16:19, David Vrabel wrote: @@ -1221,6 +1277,8 @@ void notify_via_xen_event_channel(struct domain *ld, > int lport) evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); } +spin_unlock(&lchn->lock);

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread David Vrabel
On 16/06/15 16:19, David Vrabel wrote: >>> @@ -1221,6 +1277,8 @@ void notify_via_xen_event_channel(struct domain *ld, >>> int lport) >>> evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); >>> } >>> >>> +spin_unlock(&lchn->lock); >>> + >>> spin_unlock(&ld->event_lock)

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread Jan Beulich
>>> On 16.06.15 at 17:19, wrote: > On 16/06/15 10:18, Jan Beulich wrote: > On 15.06.15 at 17:48, wrote: >>> @@ -1163,11 +1213,15 @@ int alloc_unbound_xen_event_channel( >>> if ( rc ) >>> goto out; >>> >>> +spin_lock(&chn->lock); >>> + >>> chn->state = ECS_UNBOUND; >>>

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread David Vrabel
On 16/06/15 10:18, Jan Beulich wrote: On 15.06.15 at 17:48, wrote: >> @@ -1163,11 +1213,15 @@ int alloc_unbound_xen_event_channel( >> if ( rc ) >> goto out; >> >> +spin_lock(&chn->lock); >> + >> chn->state = ECS_UNBOUND; >> chn->xen_consumer = get_xen_consumer(no

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread David Vrabel
On 16/06/15 10:51, Jan Beulich wrote: On 16.06.15 at 11:34, wrote: >> On 16/06/15 10:18, Jan Beulich wrote: >> On 15.06.15 at 17:48, wrote: @@ -609,21 +662,18 @@ int evtchn_send(struct domain *ld, unsigned int lport) struct domain *rd; intrport,

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread Jan Beulich
>>> On 16.06.15 at 11:34, wrote: > On 16/06/15 10:18, Jan Beulich wrote: > On 15.06.15 at 17:48, wrote: >>> @@ -609,21 +662,18 @@ int evtchn_send(struct domain *ld, unsigned int lport) >>> struct domain *rd; >>> intrport, ret = 0; >>> >>> -spin_lock(&ld->event_lock

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread David Vrabel
On 16/06/15 10:18, Jan Beulich wrote: On 15.06.15 at 17:48, wrote: >> @@ -609,21 +662,18 @@ int evtchn_send(struct domain *ld, unsigned int lport) >> struct domain *rd; >> intrport, ret = 0; >> >> -spin_lock(&ld->event_lock); >> - >> -if ( unlikely(!port_is_val

Re: [Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-16 Thread Jan Beulich
>>> On 15.06.15 at 17:48, wrote: > @@ -609,21 +662,18 @@ int evtchn_send(struct domain *ld, unsigned int lport) > struct domain *rd; > intrport, ret = 0; > > -spin_lock(&ld->event_lock); > - > -if ( unlikely(!port_is_valid(ld, lport)) ) > -{ > -spin_unlo

[Xen-devel] [PATCHv2 3/5] evtchn: use a per-event channel lock for sending events

2015-06-15 Thread David Vrabel
When sending an event, use a new per-event channel lock to safely validate the event channel state. This new lock must be held when changing event channel state. To avoid having to take the remote event channel locks when sending to an interdomain event channel, the local and remote channel locks