Re: [PATCH v5 01/15] libxl: Design of an async API to issue QMP commands to QEMU

From: Anthony PERARD <anthony.perard@citrix.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH v5 01/15] libxl: Design of an async API to issue QMP commands to QEMU
Date: Thu, 11 Oct 2018 15:29:32 +0100	[thread overview]
Message-ID: <20181011142932.GI1331@perard.uk.xensource.com> (raw)
In-Reply-To: <20181010234901.GA4138@mail-itl>

On Thu, Oct 11, 2018 at 01:49:01AM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 07, 2018 at 04:10:50PM +0100, Anthony PERARD wrote:
> > + * Only one connection at a time can be made to one QEMU, so avoid keeping a
> > + * libxl__ev_qmp Connected for to long and call libxl__ev_qmp_dispose as soon
> > + * as it is not needed anymore.
> 
> From where this limitation comes? Was that true before? I ask, because
> that limitation would ease Linux-based stubdomain case, where QMP over
> console have indeed only a single channel.

Actually, it is more like the QMP server will only talk to one client
(of a socket) at a time. You can initiate several connect() syscall to
the QMP unix-socket, but there is only the first one connection that
will have QMP activity, the other connection will wait. Once the first
connection is disconnected, the second connection will have QMP
activities.

So the limitation comes from QEMU, you will still need to be carefull
with QMP over console and only send one command at a time.

> > + *
> > + * Possible states of a libxl__ev_qmp:
> > + *  Undefined
> > + *    Might contain anything.
> > + *  Idle
> > + *    Struct contents are defined enough to pass to any libxl__ev_qmp_*
> > + *    function.
> > + *    The struct does not contain references to any allocated private resources
> > + *    so can be thrown away.
> > + *  Active
> > + *    Currently waiting for the callback to be called.
> > + *    _dispose must be called to reclaim resources.
> > + *  Connected
> > + *    Struct contain allocated ressources.
> > + *    Calling _send() with this same ev will use the same QMP connection.
> > + *    _dispose() must be called to reclaim resources.
> > + *
> > + * libxl__ev_qmp_init: Undefined/Idle -> Idle
> > + *
> > + * libxl__ev_qmp_send: Idle/Connected -> Active (on error: Idle)
> 
> Does it also mean libxl__ev_qmp_init or libxl__ev_qmp_send should deal
> with connecting to qemu, which _does not know it is a new connection_,
> so will not send a greeting etc? In case of QMP over console, there is
> no OOB method to signal open/close (at least not easily). I implemented
> rather hacky/incomplete way to reset QMP connection - or rather - send
> greeting again, but that may result in confusing situations, like
> QEMU sending response to previous command to unsuspecting new libxl
> client.

libxl__ev_qmp_send does deal with connecting to QEMU, and it _does_ know
it is a new connection simply because we currently use a unix socket and
that works on connection-mode.

As for how greeting works: QEMU initiate this phase, a client (libxl)
only as to react. QEMU would send "Hi I'm QEMU 3.0" to new connections.

So in the case of QMP-over-console, maybe the client could try to send
the command, and if QEMU reply with "please do greeting" (actually it's
capability negociation) first the we just need to do it.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel