On Thu, Feb 03, 2022 at 18:23:25 +0100, Michal Prívozník wrote:
> On 2/3/22 15:51, Peter Krempa wrote:
> > This API has the same semantics as 'virDomainQemuMonitorCommand' but
> > accepts file descriptors which are then forwarded to qemu.
> >
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> > include/libvirt/libvirt-qemu.h | 6 +++
> > src/driver-hypervisor.h | 8 ++++
> > src/libvirt-qemu.c | 71 +++++++++++++++++++++++++++++
> > src/libvirt_qemu.syms | 5 ++
> > src/qemu_protocol-structs | 9 ++++
> > src/remote/qemu_protocol.x | 20 +++++++-
> > src/remote/remote_daemon_dispatch.c | 42 +++++++++++++++++
> > src/remote/remote_driver.c | 40 ++++++++++++++++
> > 8 files changed, 200 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h
> > index 0cc2872821..eed691ec91 100644
> > --- a/include/libvirt/libvirt-qemu.h
> > +++ b/include/libvirt/libvirt-qemu.h
> > @@ -37,6 +37,12 @@ typedef enum {
> >
> > int virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd,
> > char **result, unsigned int flags);
> > +int virDomainQemuMonitorCommandWithFiles(virDomainPtr domain,
> > + const char *cmd,
> > + unsigned int nfiles,
> > + int *files,
>
> Do we perhaps want to have another argument for fdOut (e.g. when QEMU
> would want to return an FD)? I don't think there is a command that would
> do that now, but who knows, maybe there will be someday.
I can wire up the arguments into the public API, that should be easy
enough.
>
> > + char **result,
> > + unsigned int flags);
> >
> > virDomainPtr virDomainQemuAttach(virConnectPtr domain,
> > unsigned int pid_value,
[...]
> > diff --git a/src/libvirt-qemu.c b/src/libvirt-qemu.c
> > index 1afb5fe529..1dbe0cba54 100644
> > --- a/src/libvirt-qemu.c
> > +++ b/src/libvirt-qemu.c
> > @@ -96,6 +96,77 @@ virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd,
> > }
> >
> >
> > +/**
> > + * virDomainQemuMonitorCommandWithFiles:
> > + * @domain: a domain object
> > + * @cmd: the qemu monitor command string
> > + * @nfiles: number of filedescriptors passed in @files
> > + * @files: filedescriptors to be passed to qemu with the command
> > + * @result: a string returned by @cmd
> > + * @flags: bitwise-or of supported virDomainQemuMonitorCommandFlags
> > + *
> > + * This API is QEMU specific, so it will only work with hypervisor
> > + * connections to the QEMU driver with local connections using the unix socket.
> > + *
> > + * Send an arbitrary monitor command @cmd with file descriptors @files to
> > + * @domain through the qemu monitor. There are several requirements to safely
> > + * and successfully use this API:
> > + *
> > + * - A @cmd that queries state without making any modifications is safe
> > + * - A @cmd that alters state that is also tracked by libvirt is unsafe,
> > + * and may cause libvirtd to crash
> > + * - A @cmd that alters state not tracked by the current version of
> > + * libvirt is possible as a means to test new qemu features before
> > + * they have support in libvirt, but no guarantees are made to safety
> > + *
> > + * If VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP is set, the command is
> > + * considered to be a human monitor command and libvirt will automatically
> > + * convert it into QMP if needed. In that case the @result will also
> > + * be converted back from QMP.
> > + *
> > + * If successful, @result will be filled with the string output of the
> > + * @cmd, and the caller must free this string.
> > + *
> > + * Returns 0 in case of success, -1 in case of failure
> > + */
> > +int
> > +virDomainQemuMonitorCommandWithFiles(virDomainPtr domain,
> > + const char *cmd,
> > + unsigned int nfiles,
> > + int *files,
> > + char **result,
> > + unsigned int flags)
> > +{
> > + virConnectPtr conn;
> > +
> > + VIR_DOMAIN_DEBUG(domain, "cmd=%s, nfiles=%u, files=%p, result=%p, flags=0x%x",
> > + cmd, nfiles, files, result, flags);
> > +
> > + virResetLastError();
> > +
> > + virCheckDomainReturn(domain, -1);
> > + conn = domain->conn;
> > +
> > + virCheckNonNullArgGoto(result, error);
> > + virCheckReadOnlyGoto(conn->flags, error);
>
> Missing VIR_DRV_SUPPORTS_FEATURE(conn->driver, conn,
> VIR_DRV_FEATURE_FD_PASSING); check.
Ah, so this is how that's supposed to work :D.
