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

Re: [Xen-devel] [PATCH v2 1/1] evtchn: make EVTCHNOP_reset suitable for kexec



>>> On 30.07.14 at 15:59, <vkuznets@xxxxxxxxxx> wrote:
> "Jan Beulich" <JBeulich@xxxxxxxx> writes:
> 
>>>>> On 30.07.14 at 15:26, <vkuznets@xxxxxxxxxx> wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -957,6 +957,17 @@ static long evtchn_reset(evtchn_reset_t *r)
>>>      for ( i = 0; port_is_valid(d, i); i++ )
>>>          (void)__evtchn_close(d, i);
>>>  
>>> +    if ( (d == current->domain) && d->evtchn_fifo )
>>> +    {
>>> +        /*
>>> +         * Guest domain called EVTCHNOP_reset with DOMID_SELF, destroying
>>> +         * FIFO event array and control blocks, resetting evtchn_port_ops 
> to
>>> +         * evtchn_port_ops_2l.
>>> +         */
>>
>> At the very least comment and code should match. In the case here I
>> think you want to change the code: Replace "d == current->domain"
>> with "dom == DOMID_SELF", leaving the unaltered behavior still
>> available when a domain passes its own ID.
> 
> Thanks, missed that case. Is there a reason why unaltered behavior is
> better in that case? I understand it gives a choice but it would look
> very unobvious...

No, it's indeed solely for the caller to have a way to pick between both
behaviors.

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®.