|
[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.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |