[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 |