The xenbus thread didn't send notification to other end when it expected more data or consumed responses, which led to stalling the ring from time to time.
This is the culprit that guest was less responsive when using stubdom because the device model was stalled. Fix this by sending notification to the other end when it consumes a message. A bunch of memory barriers are also added to ensure correctness. Signed-off-by: Wei Liu <wei.l...@citrix.com> --- xenbus/xenbus.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c index 4613ed6..0ab387a 100644 --- a/xenbus/xenbus.c +++ b/xenbus/xenbus.c @@ -237,6 +237,7 @@ static void xenbus_thread_func(void *ign) event->path = data; event->token = event->path + strlen(event->path) + 1; + mb(); xenstore_buf->rsp_cons += msg.len + sizeof(msg); for (watch = watches; watch; watch = watch->next) @@ -262,9 +263,13 @@ static void xenbus_thread_func(void *ign) req_info[msg.req_id].reply, MASK_XENSTORE_IDX(xenstore_buf->rsp_cons), msg.len + sizeof(msg)); + mb(); xenstore_buf->rsp_cons += msg.len + sizeof(msg); wake_up(&req_info[msg.req_id].waitq); } + + wmb(); + notify_remote_via_evtchn(start_info.store_evtchn); } } } -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel