|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv1] evtchn: don't reuse ports that are still "busy"
>>> On 30.11.15 at 18:59, <david.vrabel@xxxxxxxxxx> wrote:
> When using the FIFO ABI a guest may close an event channel that is
> still LINKED. If this port is reused, subsequent events may be lost
> because they may become pending on the wrong queue.
>
> This could be fixed by requiring guests to only close event channels
> that are not linked. This is difficult since: a) irq cleanup in the
> guest may be done in a context that cannot wait for the event to be
> unlinked; b) the guest may attempt to rebind a PIRQ whose previous
> close is still pending; and c) existing guests already have the
> problematic behaviour.
>
> Instead, simply check a port is not "busy" (i.e., it's not linked)
> before reusing it.
I agree with the reasoning, but see below.
> --- a/xen/common/event_2l.c
> +++ b/xen/common/event_2l.c
> @@ -74,6 +74,12 @@ static bool_t evtchn_2l_is_masked(struct domain *d,
> return test_bit(evtchn->port, &shared_info(d, evtchn_mask));
> }
>
> +static bool_t evtchn_2l_is_busy(struct domain *d,
> + const struct evtchn *evtchn)
> +{
> + return 0;
> +}
> +
> static void evtchn_2l_print_state(struct domain *d,
> const struct evtchn *evtchn)
> {
> @@ -90,6 +96,7 @@ static const struct evtchn_port_ops evtchn_port_ops_2l =
> .unmask = evtchn_2l_unmask,
> .is_pending = evtchn_2l_is_pending,
> .is_masked = evtchn_2l_is_masked,
> + .is_busy = evtchn_2l_is_busy,
> .print_state = evtchn_2l_print_state,
> };
Perhaps better to avoid introduction of the function by having the
wrapper check for NULL?
> --- 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)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |