Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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(&current->domain->event_lock);
>>>>          rc = evtchn_unmask(unmask.port);
>>>> -        spin_unlock(&current->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