Re: [Xen-devel] [PATCHv1] evtchn: don't reuse ports that are still "busy"

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.12.15 at 15:04, <david.vrabel@xxxxxxxxxx> wrote:
> On 01/12/15 12:49, Jan Beulich wrote:
>>>>> On 30.11.15 at 18:59, <david.vrabel@xxxxxxxxxx> wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -170,7 +170,8 @@ static int get_free_port(struct domain *d)
>>>      {
>>>          if ( port > d->max_evtchn_port )
>>>              return -ENOSPC;
>>> -        if ( evtchn_from_port(d, port)->state == ECS_FREE )
>>> +        chn = evtchn_from_port(d, port);
>>> +        if ( chn->state == ECS_FREE && !evtchn_port_is_busy(d, chn) )
>> 
>> Despite the reasonable arguments you give this looks very wrong:
>> How can a free port still be busy? Could we have a new ECS_* and
>> require guests to notify the hypervisor when they unlinked an
>> already closed port (while "close" would transition busy ports into
>> that new state)?
> 
> I would look at it as: The channel object is free, but the corresponding
> ABI specific port object is busy.  So it doesn't seem unreasonable to
> check the state of both objects.

While I think they're really tied together (namely due to how
get_free_port() works), yes - that's a way to view it, taking the
tying together as an implementation detail.

However, in that case it seems wrong to pass the channel pointer
to the is_busy() hook.

> What you suggest (adding an additional call) would break all existing
> guests that would not make the unlinked call, leaving the event channel
> in a state where it cannot be reused.

True.

Jan


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