[PATCH 1/5] lib: Introduce 'virDomainQemuMonitorCommandWithFiles'

[Peter Krempa]

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 at redhat.com>
> > ---
> >  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.