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

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

>>> On 01.12.15 at 15: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.
> Guests should still drain any queues for VCPUs that are being
> offlined, or the port will become unusable until the VCPU is onlined
> and starts processing events again.
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with one remark (no reason to cut another version):

> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -139,6 +139,11 @@ struct evtchn_port_ops {
>      void (*unmask)(struct domain *d, struct evtchn *evtchn);
>      bool_t (*is_pending)(struct domain *d, const struct evtchn *evtchn);
>      bool_t (*is_masked)(struct domain *d, const struct evtchn *evtchn);
> +    /*
> +     * Is the port unavailable because it's still being cleaned up
> +     * after being closed?
> +     */
> +    bool_t (*is_busy)(struct domain *d, u32 port);

I realize there's a lot of u32-s for port numbers, but I think we
should really get used to using evtchn_port_t for those.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.