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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4075 bytes --]

On Fri, Sep 07, 2018 at 04:10:50PM +0100, Anthony PERARD wrote:
> All the functions will be implemented in later patches.
> 
> This patch includes the API that libxl can use to send QMP commands to
> QEMU.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 
> Notes:
>     v5:
>         some changes in the comment
> 
>  tools/libxl/libxl_internal.h | 72 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 70 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 802382c704..979a9947f0 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -202,6 +202,8 @@ typedef struct libxl__ao libxl__ao;
>  typedef struct libxl__aop_occurred libxl__aop_occurred;
>  typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
>  typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
> +typedef struct libxl__json_object libxl__json_object;
> +typedef struct libxl__carefd libxl__carefd;
>  
>  typedef struct libxl__domain_create_state libxl__domain_create_state;
>  typedef void libxl__domain_create_cb(struct libxl__egc *egc,
> @@ -357,6 +359,72 @@ struct libxl__ev_child {
>      LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
>  };
>  
> +/*
> + * QMP asynchronous calls
> + *
> + * This facility allows a command to be sent to QEMU, and the response to be
> + * handed to a callback function.
> + *
> + * Commands can be chained, with a same connection. (e.g. "add-fd" will need to
> + * be chained to the next command). A libxl__ev_qmp can be reused when the
> + * callback is been called in order to use the same connection.
> + *
> + * 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.

> + *
> + * 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.

> + *    Sends a command to QEMU.
> + *    callback will be called when a response is received or when an error
> + *    as occured.
> + *
> + * libxl__ev_qmp_dispose: Connected/Active/Idle -> Idle
> + *
> + * callback: When called: Active -> Connected
> + *    When called, ev is Connected and can be reused or disposed of.
> + *    If an error occured, it is called with response == NULL and the error
> + *    code in rc.
> + *    The callback is only called once.
> + */

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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