On Mon, Jul 09, 2018 at 22:56:53 -0500, Chris Venteicher wrote:
Commit makes starting a single persistent QEMU instance possible for
use
over multiple independent QMP commands without starting and stopping
QEMU for each QMP command or command type.
Commit allows functions outside qemu_capabilities
(ex. qemuConnectBaselineHypervisorCPU in qemu_driver)
requiring multiple different QMP messages to be sent to QEMU to issue
those requests over a single QMP Command Channel without starting and
stopping QEMU for each independent QMP Command usage.
Commit moves following to global scope so parent function can
maintain QEMU instance over multiple QMP commands / command types:
virQEMUCapsInitQMPCommand
virQEMUCapsInitQMPCommandFree
Commit Introduces virQEMUCapsNewQMPCommandConnection to Start and
connect to QEMU so QMP commands can be performed.
The new reusable function isolates code for starting QEMU and
establishing Monitor connections from code for obtaining capabilities so
that arbitrary QMP commands can be exchanged with QEMU.
---
src/qemu/qemu_capabilities.c | 61 +++++++++++++++++++++++-------------
src/qemu/qemu_capabilities.h | 26 +++++++++++++++
2 files changed, 66 insertions(+), 21 deletions(-)
Just a high level review since this patch will require some significant
changes...
Your approach will not work because all callers would end up using the
same monitor socket for to the QEMU process. And there might be several
concurrent callers which would want to call some QMP command to do the
job, each of them spawning their own QEMU process. You'd need to give
each caller a unique monitor socket path.
I think this should be reworked into a general code (ideally placed in
qemu_process.c), which would then be called by the QEMU capabilities
code and from APIs which need to call QEMU.
Jirka