mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Marek Marczykowski-Górecki
83c845033d
Access to QMP of QEMU in Linux stubdomain is possible over vchan connection. Handle the actual vchan connection in a separate process (vchan-socket-proxy). This simplified integration with QMP (already quite complex), but also allows preliminary filtering of (potentially malicious) QMP input. Since only one client can be connected to vchan server at the same time and it is not enforced by the libxenvchan itself, additional client-side locking is needed. It is implicitly implemented by vchan-socket-proxy, as it handle only one connection at a time. Note that qemu supports only one simultaneous client on a control socket anyway (but in UNIX socket case, it enforce it server-side), so it doesn't add any extra limitation. libxl qmp client code already has locking to handle concurrent access attempts to the same qemu qmp interface. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Squash in changes of regenerated autotools files. 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. Also call libxl__qmp_cleanup() to remove the unix sockets used by vchan-socket-proxy. vchan-socket-proxy only creates qmp-libxl-$domid, and libxl__qmp_cleanup removes that as well as qmp-libxenstat-$domid. However, it tolerates ENOENT, and a stray qmp-libxenstat-$domid should not exist. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>