Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-11-02 at 15:53 +0000, Wei Liu wrote:
> On Mon, Nov 02, 2015 at 03:08:26PM +0000, Ian Campbell wrote:
> > On Mon, 2015-11-02 at 15:00 +0000, Wei Liu wrote:
> > > On Mon, Nov 02, 2015 at 12:14:50PM +0000, Ian Campbell wrote:
> > > > On Mon, 2015-10-26 at 09:47 +0000, Wei Liu wrote:
> > > > > 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 at the right
> > > > > places.
> > > > 
> > > > Could any of this code benefit from using the various macros in
> > > > ring.h
> > > > which produce or consume entries on the ring and return a _notify
> > > > bit?
> > > > 
> > > 
> > > The bug is it doesn't send notification at all. The existing code in
> > > Linux doesn't seem to care about mitigating notifications -- xenbus
> > > is
> > > supposed to exchange small amount of information anyway so whether a
> > > few
> > > more notifications are sent is not essential. I think it would be
> > > better
> > > if we follow something that works at this stage.
> > > 
> > > The use of ring macro can be considered an improvement but not
> > > essential to fix the bug. It can be considered as improvement in the
> > > future.
> > 
> > My reason for suggesting it was more that we trust that those macros
> > are
> > already correct, compared with needing to reason from scratch about the
> > open coded version used in this code which is what appeared to be going
> > on.
> > 
> 
> I don't think macros help here. Xenstore initialisation doesn't follow
> conventional frontend and backend drivers, so the macros don't really
> apply to it -- not without some refactoring.

AH, ok then.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel