Re: [Xen-devel] Re: [PATCH] libxl, Introduce a QMP client

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-06-07 at 12:49 +0100, Anthony PERARD wrote:
> On Tue, Jun 7, 2011 at 09:58, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Mon, 2011-06-06 at 19:31 +0100, Stefano Stabellini wrote:
> >> On Mon, 6 Jun 2011, Ian Campbell wrote:
> >> > I think we should try where possible to keep this stuff entirely within
> >> > libxl. The existing libxl event API is a bit of a mess but I think if it
> >> > were cleaned up (IanJ has a plan I think) then it would be the right
> >> > place to integrate the libxl and caller event loops.
> >> >
> >> > For the time being though I think libxl should provide the fd and not
> >> > expect the caller to construct the path and open it etc. IOW
> >> > libxl_qmp_initialize should not take a socket option, it should
> >> > construct the path, do the open internally and return the fd.
> >>
> >> I agree on this.
> >>
> >> Libxl needs to use QMP internally for things like the serial. Libxl
> >> cannot rely on the caller (xl) to select on the fd and call
> >> libxl_qmp_do_next later for libxl to put the appropriate serial device
> >> on xenstore.
> >> Ideally QMP should be completely hidden inside libxl.
> >>
> >> I think all the initialization details should be handled internally by
> >> libxl_domain_create_new, including opening the QMP connection and
> >> reading back the serial device.
> >
> > Yes I think it would be better to have libxl open a short lived QMP
> > channel for specific operations entirely internally (including closing
> > it again).
> 
> Ok, I will change that.
> 
> > If we don't do this then we need to be mindful of multithreaded users of
> > the library multiplexing over a single channel and all the inherent
> > complexity of matching replies to requests, blocking the caller threads,
> > handling async notifications while a request is in progress etc etc.
> >
> > Probably we will also need a long-running channel dedicated to feeding
> > out into the user's event loop to handle async notifications etc.
> >
> > How does QMP handle the async notifications with multiple connected
> > clients? I suppose they must all see them (or else writing a client
> > would be virtually impossible), in which case the function-specific
> > connections can simply discard them.
> 
> Actually, QEMU doesn't seem to handle more than one client at a time
> with a single socket.

That seems like a pretty obvious short coming, do you know if it is a
deliberate policy or just a case of not implemented yet?

>  For more client, we can always open more than
> one QMP server with different path/port. In this case, they will be
> handle separately by QEMU.

Problem is determining the correct number to create when we start qemu.

> To handle the async request, it's relatively easy. When we send a
> command, we can add an "id" to this request and the id will be part of
> the answer. I use that to handle the replies.

Most of the uses of QMP (at least within libxl) are likely to want to be
synchronous though, e.g. libxl functions usually do not return to the
user in a semi completed state and require a callback for completion.

This means that we need a means to arrange to wait for a specific
response, which in a multithreaded user may mean blocking threads until
their response comes in and waking them etc, ensuring that there is one
(and only one) thread actually handling the incoming requests to do the
dispatch/handle async notifications etc. It's not the end of the world
but it does add complexity within the library and a dependency on a
threading library which IIRC we currently manage to avoid...

> For the QEMU event/async notification, indeed, all clients receive them.
> 



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