We need to kill the vchan-socket-proxy so we don't leak the daemonized
processes.  libxl__stubdomain_is_linux_running works against the
guest_domid, but the xenstore path is beneath the stubdomain.  This
leads to the use of libxl_is_stubdom in addition to
libxl__stubdomain_is_linux_running so that the stubdomain calls kill for
the qmp-proxy

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
libxl__qmp_cleanup was considered, but it is not called for guests with
a stubdomain.
---
 tools/libxl/libxl_domain.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index fef2cd4e13..3b66e25aa7 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1260,10 +1260,17 @@ static void dm_destroy_cb(libxl__egc *egc,
     libxl__destroy_domid_state *dis = CONTAINER_OF(ddms, *dis, ddms);
     STATE_AO_GC(dis->ao);
     uint32_t domid = dis->domid;
+    uint32_t target_domid;
 
     if (rc < 0)
         LOGD(ERROR, domid, "libxl__destroy_device_model failed");
 
+    if (libxl_is_stubdom(CTX, domid, &target_domid) &&
+        libxl__stubdomain_is_linux_running(gc, target_domid)) {
+        char *path = GCSPRINTF("/local/domain/%d/image/qmp-proxy-pid", domid);
+        libxl__kill_xs_path(gc, path, "QMP Proxy");
+    }
+
     dis->drs.ao = ao;
     dis->drs.domid = domid;
     dis->drs.callback = devices_destroy_cb;
-- 
2.20.1

Jason Andryuk writes ("[PATCH v5 20/21] libxl: Kill vchan-socket-proxy when cleaning up qmp"):
> We need to kill the vchan-socket-proxy so we don't leak the daemonized
> processes.  libxl__stubdomain_is_linux_running works against the
> guest_domid, but the xenstore path is beneath the stubdomain.  This
> leads to the use of libxl_is_stubdom in addition to
> libxl__stubdomain_is_linux_running so that the stubdomain calls kill for
> the qmp-proxy

In theory maybe this patch should be folded into the one that
introduces the vchan proxy.  But since this whole mode of operation is
new, having a point in the history where it leaks these is OK I
think.

Do others agree ?

For my part,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However, if possible maybe this patch could be moved to right after
the one which spawns the proxy ?

Thanks,
Ian.