[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel
On 18/06/15 13:08, Jan Beulich wrote: >>>> On 18.06.15 at 13:36, <david.vrabel@xxxxxxxxxx> wrote: >> On 18/06/15 12:30, Jan Beulich wrote: >>>>>> On 17.06.15 at 14:03, <david.vrabel@xxxxxxxxxx> wrote: >>>> --- a/xen/common/event_channel.c >>>> +++ b/xen/common/event_channel.c >>>> @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port) >>>> struct domain *d = current->domain; >>>> struct evtchn *evtchn; >>>> >>>> - ASSERT(spin_is_locked(&d->event_lock)); >>>> - >>>> if ( unlikely(!port_is_valid(d, port)) ) >>>> return -EINVAL; >>>> >>>> @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, >> XEN_GUEST_HANDLE_PARAM(void) arg) >>>> struct evtchn_unmask unmask; >>>> if ( copy_from_guest(&unmask, arg, 1) != 0 ) >>>> return -EFAULT; >>>> - spin_lock(¤t->domain->event_lock); >>>> rc = evtchn_unmask(unmask.port); >>>> - spin_unlock(¤t->domain->event_lock); >>> >>> And, looking particularly at evtchn_fifo_unmask() (and its descendant >>> evtchn_fifo_set_pending()), you get away without acquiring the port >>> lock in or around evtchn_port_unmask()? If indeed so, this one would >>> again be independent on 1, 2, and 4, i.e. could go in together with 3. >> >> Yes. This is only dependent on #3 (simplify port_is_valid()). > > I'm still not convinced that not taking the port lock is correct: It > is my understanding that e.g. the (last_vcpu_id,last_priority) pair > needs to be updated atomically. Yet nothing prevents the > (notify_vcpu_id,priority) pair now from getting updated in the > middle of it being snapshot in evtchn_fifo_set_pending(). Are you > saying this is no problem? This is serialized by the q lock. evtchn_fifo_set_pending() has never been serialized by the event lock because concurrent evtchn_send() calls with two interdomain channels from different domains would have taken different event locks. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |