Re: [Xen-devel] libxl: error handling before xenstored runs

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2011-02-10 at 11:32 +0000, Christoph Egger wrote:
> On Thursday 10 February 2011 12:24:41 Ian Campbell wrote:
> > On Thu, 2011-02-10 at 09:26 +0000, Vincent Hanquez wrote:
> > > On 10/02/11 08:55, Ian Campbell wrote:
> > > > That's the underlying bug which the heuristic is trying to avoid...
> > > >
> > > > Fundamentally the xs ring protocol is missing any way to tell if
> > > > someone is listening on the other end so you have no choice but to try
> > > > communicating and see if anyone responds.
> > > >
> > > > It's a pretty straightforward bug that the kernel does the waiting to
> > > > see if anyone responds bit with an uninterruptible sleep. I took a
> > > > quick look a little while ago but unfortunately it didn't look
> > > > straightforward to fix on the kernel side :-( I can't remember why
> > > > though.
> > >
> > > For starter, the protocol requires the messages to sit on the ring for a
> > > underdetermined amount of time (boot watches).
> > >
> > > > It might be simpler to support allowing the userspace client to
> > > > explicitly specify a timeout. I'm not sure what the impact on the ring
> > > > is of leaving unconsumed requests on the ring when the other end does
> > > > show up. Presumably the kernel driver just needs to be prepared to
> > > > swallow responses whose target has given up and gone home.
> > >
> > > No, the simplest thing to do is to use the socket connection
> > > exclusively. Just how we're doing it in XCP and XCI.
> >
> > Right but this approach doesn't work with xenstored in a stubdomain.
> > Part of the point of using the ring protocol even when this isn't the
> > case is to help ensure that it is possible and help avoid regressions
> > etc.
> >
> > > The protocol is not design to do async either, so leaving unconsumed
> > > request, could be pretty disastrous if the other end show up. Providing
> > > the kernel doesn't detect it (i don't think it does [1]), it would imply
> > > spurious reply, for example the previous waiting read on "/abc/def"
> > > could reply to a next read on "/xyz/123".
> >
> > The wire protocol includes a req_id which is echoed in the response
> > which sh/could facilitate multiplexing this sort of thing. The pvops
> > kernel currently always sets it to zero but that's just an
> > implementation detail ;-) Currently the kernel does (roughly):
> >     take_lock
> >     write_request
> >     wait_for_reply
> >     release_lock
> > instead it should/could be:
> >     take_lock(timeout)
> >     write_request (++req_id)
> >     while read_reply.req_id != req_id && not (timeout)
> >             wait some more
> >     release lock
> 
> I prefer a userland solution. Fixing Linux Dom0 doesn't help NetBSD Dom0.

Fixing the NetBSD dom0 does though.

Seriously, if kernels are lacking in functionality needed to make the
system work smoothly and correctly we should fix them, not just default
to adding hacks in userspace because it seems easier in the short term.
(Obviously if the userspace solution is the right thing to do and/or
more correct in its own right then fine lets do that).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel