Re: [libvirt PATCH 3/3] rpc/ssh: ssh_userauth_agent() is not supported on win32

[Marc-André Lureau]

Hi

On Tue, Apr 11, 2023 at 11:10 AM Michal Prívozník 
wrote:

> On 4/6/23 17:58, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > The function does not exist on win32.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  src/rpc/virnetlibsshsession.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/rpc/virnetlibsshsession.c
> b/src/rpc/virnetlibsshsession.c
> > index e71a79d0fb..e94b0d7a2e 100644
> > --- a/src/rpc/virnetlibsshsession.c
> > +++ b/src/rpc/virnetlibsshsession.c
> > @@ -60,7 +60,9 @@ typedef enum {
> >  VIR_NET_LIBSSH_AUTH_KEYBOARD_INTERACTIVE,
> >  VIR_NET_LIBSSH_AUTH_PASSWORD,
> >  VIR_NET_LIBSSH_AUTH_PRIVKEY,
> > -VIR_NET_LIBSSH_AUTH_AGENT
> > +#ifndef WIN32
> > +VIR_NET_LIBSSH_AUTH_AGENT,
> > +#endif
> >  } virNetLibsshAuthMethods;
> >
>
> I'd just drop this hunk, and ...
>
> >
> > @@ -698,6 +700,7 @@ virNetLibsshAuthenticate(virNetLibsshSession *sess)
> >  /* try to authenticate using the keyboard interactive way */
> >  ret = virNetLibsshAuthenticateKeyboardInteractive(sess,
> auth);
> >  break;
> > +#ifndef WIN32
> >  case VIR_NET_LIBSSH_AUTH_AGENT:
> >  /* try to authenticate using ssh-agent */
> >  ret = ssh_userauth_agent(sess->session, NULL);
> > @@ -708,6 +711,7 @@ virNetLibsshAuthenticate(virNetLibsshSession *sess)
> > errmsg);
> >  }
> >  break;
> > +#endif
>
>
> .. here just wrap the actual ssh_userauth_agent() call in ifdnef. The
> @ret is set to SSH_AUTH_DENIED beforehand, and later in the code a
> proper error message is reported.
>
> >  case VIR_NET_LIBSSH_AUTH_PRIVKEY:
> >  /* try to authenticate using the provided ssh key */
> >  ret = virNetLibsshAuthenticatePrivkey(sess, auth);
> > @@ -861,8 +865,13 @@
> virNetLibsshSessionAuthAddPasswordAuth(virNetLibsshSession *sess,
> >  }
> >
> >  int
> > -virNetLibsshSessionAuthAddAgentAuth(virNetLibsshSession *sess)
> > +virNetLibsshSessionAuthAddAgentAuth(virNetLibsshSession *sess
> G_GNUC_UNUSED)
> >  {
> > +#ifdef WIN32
> > +virReportError(VIR_ERR_LIBSSH, "%s",
> > +   _("Agent authentication is not supported on this
> host"));
> > +return -1;
> > +#else
> >  virNetLibsshAuthMethod *auth;
> >
> >  virObjectLock(sess);
> > @@ -873,6 +882,7 @@
> virNetLibsshSessionAuthAddAgentAuth(virNetLibsshSession *sess)
> >
> >  virObjectUnlock(sess);
> >  return 0;
> > +#endif
> >  }
> >
> >  int
>
> This hunk alone is enough to ensure agent is not available on WIN32.
>
>
Sure, that's fine with me.

thanks

Re: [libvirt PATCH 2/3] meson: drop explicit python interpreter

[Marc-André Lureau]

Hi

On Tue, Apr 11, 2023 at 11:10 AM Michal Prívozník 
wrote:

> On 4/6/23 17:58, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > meson wraps python scripts already on win32, so we end up with these
> > failing commands:
> >
> > [1/359] "C:/msys64/ucrt64/bin/meson" "--internal" "exe" "--capture"
> "src/util/virkeycodetable_atset1.h" "--" "sh"
> "C:/msys64/home/marca/src/libvirt/scripts/meson-python.sh"
> "C:/msys64/ucrt64/bin/python3.EXE" "python"
> "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/tools/keymap-gen"
> "code-table" "--lang" "stdc" "--varname" "virKeyCodeTable_atset1"
> "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/data/keymaps.csv"
> "atset1"
> > FAILED: src/util/virkeycodetable_atset1.h
> > "C:/msys64/ucrt64/bin/meson" "--internal" "exe" "--capture"
> "src/util/virkeycodetable_atset1.h" "--" "sh"
> "C:/msys64/home/marca/src/libvirt/scripts/meson-python.sh"
> "C:/msys64/ucrt64/bin/python3.EXE" "python"
> "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/tools/keymap-gen"
> "code-table" "--lang" "stdc" "--varname" "virKeyCodeTable_atset1"
> "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/data/keymaps.csv"
> "atset1"
> >
> > If LC_ALL, LANG and LC_CTYPE need to be set, it would probably be better
> > to use a meson environment() instead.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  docs/manpages/meson.build | 4 ++--
> >  docs/meson.build  | 6 ++
> >  src/admin/meson.build | 4 ++--
> >  src/esx/meson.build   | 4 ++--
> >  src/hyperv/meson.build| 2 +-
> >  src/meson.build   | 8 
> >  src/util/meson.build  | 4 ++--
> >  7 files changed, 15 insertions(+), 17 deletions(-)
>
> After this, there are still some occurrences of meson_python_prog or
> python3_prog left; mostly in locations which are never built on Windows
> (e.g. src/qemu/, src/network/ and so on. But is it worth removing them too?
>
>
If we don't have a good reason for this extra wrapping, yes. Is gitlab CI
covering enough to validate the change? Someone more familiar with libvirt
build environments should know better.

thanks

Re: [PATCH] RFC: char: deprecate usage of bidirectional pipe

[Marc-André Lureau]

Hi

On Tue, Jul 26, 2022 at 12:44 PM Daniel P. Berrangé  wrote:
>
> On Tue, Jul 26, 2022 at 12:32:32PM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > As Ed Swierk explained back in 2006:
> > https://lists.nongnu.org/archive/html/qemu-devel/2006-12/msg00160.html
> >
> > "When qemu writes into the pipe, it immediately reads back what it just
> > wrote and treats it as a monitor command, endlessly breathing its own
> > exhaust."
> >
> > This is similarly confusing when using the chardev with a serial device,
> > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2106975.
> >
> > It seems we have kept the support for bidirectional pipes for historical
> > reasons and odd systems, however it's not documented in qemu -chardev
> > options. I suggest to stop supporting it, for portability reasons.
>
> Hmm, I always assumed that in this scenario the pipe was operating
> in output-only mode. Obviously not the case with the code as it
> exists, but perhaps this would be useful ?  eg its good as a serial
> console logging mechanism at least.

The current "-chardev pipe,id=id,path=path" option handling will first
check the presence of unidirectional "path.in" & "path.out" (although
they are opened RDWR...), and fallback on bidirectional "path".

We could allow for the presence of "path.out" alone, although this may
be a behaviour/breaking change:

diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
index 7db963035e..f78bcd7daf 100644
--- a/chardev/char-pipe.c
+++ b/chardev/char-pipe.c
@@ -137,12 +137,12 @@ static void qemu_chr_open_pipe(Chardev *chr,
 g_free(filename_in);
 g_free(filename_out);
 if (fd_in < 0 || fd_out < 0) {
+if (fd_out >= 0) {
+goto out;
+}
 if (fd_in >= 0) {
 close(fd_in);
 }
-if (fd_out >= 0) {
-close(fd_out);
-}
 warn_report("Support for bidirectional pipe is deprecated,");
 warn_report("please use portable one-way pipes instead (%s.in
& %s.out).",
 filename, filename);
@@ -152,6 +152,7 @@ static void qemu_chr_open_pipe(Chardev *chr,
 return;
 }
 }
+out:
 qemu_chr_open_fd(chr, fd_in, fd_out);


or we introduce a new "access=write" option, or a new chardev type ?

>
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  docs/about/deprecated.rst | 6 ++
> >  chardev/char-pipe.c   | 4 
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 7ee26626d5cf..dd5ca30d527b 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -45,6 +45,12 @@ transmit audio through the VNC protocol.
> >  ``tty`` and ``parport`` are aliases that will be removed. Instead, the
> >  actual backend names ``serial`` and ``parallel`` should be used.
> >
> > +``-chardev pipe`` support for bidirectional pipes (since 7.1)
> > +
> > +
> > +For portability reasons, the support for bidirectional ``pipe`` will
> > +be removed. Instead, use ``file.in`` & ``file.out`` unidirectional pipes.
> > +
> >  Short-form boolean options (since 6.0)
> >  ''
> >
> > diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
> > index 66d3b8509183..7db963035e7d 100644
> > --- a/chardev/char-pipe.c
> > +++ b/chardev/char-pipe.c
> > @@ -27,6 +27,7 @@
> >  #include "qemu/main-loop.h"
> >  #include "qemu/module.h"
> >  #include "qemu/option.h"
> > +#include "qemu/error-report.h"
> >  #include "chardev/char.h"
> >
> >  #ifdef _WIN32
> > @@ -142,6 +143,9 @@ static void qemu_chr_open_pipe(Chardev *chr,
> >  if (fd_out >= 0) {
> >  close(fd_out);
> >  }
> > +warn_report("Support for bidirectional pipe is deprecated,");
> > +warn_report("please use portable one-way pipes instead (%s.in & 
> > %s.out).",
> > +filename, filename);
> >  TFR(fd_in = fd_out = qemu_open_old(filename, O_RDWR | O_BINARY));
> >  if (fd_in < 0) {
> >  error_setg_file_open(errp, errno, filename);
> > --
> > 2.37.0.rc0
> >
>
> With regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>

Re: [libvirt PATCH v2 0/4] Enable copy/paste for vnc displays

[Marc-André Lureau]

Hi Jonathon

On Thu, Mar 24, 2022 at 11:26 PM Jonathon Jongsma 
wrote:

> This patch series enables support for the qemu-vdagent character device
> which
> enables copy/paste support between guest and client when using vnc
> graphics.
>
> The guest must be configured with something like the following:
>
> 
>   
> 
> 
>   
>   
> 
>
> Copy/paste sync requires a vnc client that has support for copy/paste
> commands.
> Currently virt-viewer does not work, but the version of tigervnc provided
> by
> fedora (executable name 'vncviewer') does work.
>
> More details about this device on Gerd's blog:
> https://www.kraxel.org/blog/2021/05/qemu-cut-paste/
>
> For now I have left the target to be configurable to match the spicevmc
> channel, although Marc-Andre has suggested to simply hard-code it to the
> virtio
> name com.redhat.spice.0
>
> Changes in v2:
>  - change xml syntax to use  and  sub-elements of
> 
>defined in the same way as they are for the spice display.
>  - fix a build failure when apparmor was enabled
>  - Add another test for when features are turned off
>
>
Is there anything missing to merge this?
thanks


> Jonathon Jongsma (4):
>   qemu: add capability for qemu-vdagent chardev
>   Rename virDomainGraphicsSpiceMouseMode to virDomainMouseMode
>   conf: add qemu-vdagent channel
>   qemu: add support for qemu-vdagent channel
>
>  docs/formatdomain.rst | 23 ++
>  src/conf/domain_conf.c| 70 +--
>  src/conf/domain_conf.h| 24 ---
>  src/conf/domain_validate.c|  1 +
>  src/conf/schemas/domaincommon.rng | 51 +-
>  src/libvirt_private.syms  |  4 +-
>  src/libxl/libxl_conf.c|  8 +--
>  src/libxl/xen_xl.c| 16 ++---
>  src/qemu/qemu_capabilities.c  |  2 +
>  src/qemu/qemu_capabilities.h  |  1 +
>  src/qemu/qemu_command.c   | 32 +++--
>  src/qemu/qemu_monitor_json.c  | 27 +++
>  src/qemu/qemu_process.c   |  1 +
>  src/qemu/qemu_validate.c  |  9 +++
>  src/security/security_apparmor.c  |  2 +
>  src/security/security_dac.c   |  2 +
>  .../caps_6.1.0.x86_64.xml |  1 +
>  .../caps_6.2.0.aarch64.xml|  1 +
>  .../caps_6.2.0.x86_64.xml |  1 +
>  .../caps_7.0.0.x86_64.xml |  1 +
>  ...l-qemu-vdagent-features.x86_64-latest.args | 41 +++
>  .../channel-qemu-vdagent-features.xml | 37 ++
>  .../channel-qemu-vdagent.x86_64-latest.args   | 41 +++
>  .../qemuxml2argvdata/channel-qemu-vdagent.xml | 37 ++
>  tests/qemuxml2argvtest.c  |  2 +
>  ...el-qemu-vdagent-features.x86_64-latest.xml | 58 +++
>  .../channel-qemu-vdagent.x86_64-latest.xml| 58 +++
>  tests/qemuxml2xmltest.c   |  2 +
>  tests/testutilsqemu.c |  1 +
>  29 files changed, 500 insertions(+), 54 deletions(-)
>  create mode 100644
> tests/qemuxml2argvdata/channel-qemu-vdagent-features.x86_64-latest.args
>  create mode 100644
> tests/qemuxml2argvdata/channel-qemu-vdagent-features.xml
>  create mode 100644
> tests/qemuxml2argvdata/channel-qemu-vdagent.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.xml
>  create mode 100644
> tests/qemuxml2xmloutdata/channel-qemu-vdagent-features.x86_64-latest.xml
>  create mode 100644
> tests/qemuxml2xmloutdata/channel-qemu-vdagent.x86_64-latest.xml
>
> --
> 2.35.1
>
>
>

-- 
Marc-André Lureau

Re: [libvirt PATCH v3 00/16] Add QEMU "-display dbus" support

[Marc-André Lureau]

Hi

On Wed, Dec 22, 2021 at 11:45 PM  wrote:

> From: Marc-André Lureau 
>
> Hi,
>
> This series implements supports for the uQEMU "-display dbus" support, that
> landed earlier this week for 7.0.
>
> By default, libvirt will start a private VM bus (sharing and reusing the
> existing "vmstate" VM bus & code).
>
> The feature set should cover the needs to replace Spice as local client of
> choice,
> including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and
> arbitrary
> chardev/channels (for serial etc).
>
> The test Gtk4 client is also in progress, currently in development at
> https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies,
> such as
> zbus, require an upcoming release. virt-viewer & boxes will need a port to
> Gtk4
> to make use of the shared widget.
>
> Comments welcome, as we can still adjust the QEMU side etc.
>

4 months later, the QEMU bits are now in the last release. This series has
certainly bit rot. Could someone give it a review before I attempt rebasing?

thanks


>
> thanks
>
> v3: after QEMU 7.0 dev cycle opening and merge
>  - rebased
>  - add 7.0 x86-64 capabilities (instead of tweaking 6.2)
>  - fix version annotations
>
> Marc-André Lureau (16):
>   qemu: add chardev-vdagent capability check
>   qemu: add -display dbus capability check
>   qemucapabilitiestest: Add x64 test data for the qemu-7.0 development
> cycle
>   conf: add 
>   qemu: start the D-Bus daemon for the display
>   qemu: add -display dbus support
>   virsh: refactor/split cmdDomDisplay()
>   virsh: report the D-Bus bus URI for domdisplay
>   conf: add  support
>   qemu: add audio type 'dbus'
>   conf: add dbus 
>   qemu: add dbus clipboard sharing
>   conf: add 
>   qemu: add -chardev dbus support
>   qemu: add usbredir type 'dbus'
>   docs: document  type dbus
>
>  NEWS.rst  | 7 +-
>  docs/formatdomain.rst |43 +-
>  docs/schemas/basictypes.rng   | 7 +
>  docs/schemas/domaincommon.rng |71 +
>  src/bhyve/bhyve_command.c | 1 +
>  src/conf/domain_conf.c|   141 +-
>  src/conf/domain_conf.h|15 +
>  src/conf/domain_validate.c|41 +-
>  src/libxl/libxl_conf.c| 1 +
>  src/qemu/qemu_capabilities.c  | 8 +
>  src/qemu/qemu_capabilities.h  | 4 +
>  src/qemu/qemu_command.c   |77 +-
>  src/qemu/qemu_domain.c| 1 +
>  src/qemu/qemu_driver.c|10 +-
>  src/qemu/qemu_extdevice.c |13 +
>  src/qemu/qemu_hotplug.c   | 1 +
>  src/qemu/qemu_monitor_json.c  |10 +
>  src/qemu/qemu_process.c   |41 +-
>  src/qemu/qemu_validate.c  |33 +
>  src/security/security_dac.c   | 2 +
>  src/vmx/vmx.c | 1 +
>  .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  |   231 +
>  .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  |   237 +
>  tests/domaincapsdata/qemu_7.0.0.x86_64.xml|   231 +
>  .../caps_6.1.0.x86_64.xml | 1 +
>  .../caps_6.2.0.aarch64.xml| 1 +
>  .../caps_6.2.0.x86_64.xml | 1 +
>  .../caps_7.0.0.x86_64.replies | 37335 
>  .../caps_7.0.0.x86_64.xml |  3720 ++
>  .../graphics-dbus-address.args|30 +
>  .../graphics-dbus-address.xml |35 +
>  .../qemuxml2argvdata/graphics-dbus-audio.args |33 +
>  .../qemuxml2argvdata/graphics-dbus-audio.xml  |45 +
>  .../graphics-dbus-chardev.args|32 +
>  .../graphics-dbus-chardev.xml |43 +
>  .../graphics-dbus-clipboard.args  |31 +
>  .../graphics-dbus-clipboard.xml   |35 +
>  tests/qemuxml2argvdata/graphics-dbus-p2p.args |30 +
>  tests/qemuxml2argvdata/graphics-dbus-p2p.xml  |33 +
>  .../graphics-dbus-usbredir.args   |34 +
>  .../graphics-dbus-usbredir.xml|30 +
>  tests/qemuxml2argvdata/graphics-dbus.args |30 +
>  tests/qemuxml2argvdata/graphics-dbus.xml  |33 +
>  tests/qemuxml2argvtest.c  |22 +
>  .../graphics-dbus-address.xml | 1 +
>  .../graphics-dbus-audio.xml   | 1 +
>  .../graphics-dbus-chardev.xml | 1 +
>  .../graphics-dbus-clipboard.xml  

Re: [libvirt PATCH v2 4/4] qemu: add support for qemu-vdagent channel

[Marc-André Lureau]

Hi,

On Thu, Mar 24, 2022 at 11:26 PM Jonathon Jongsma  wrote:
>
> Implement the qemu-vdagent channel introduced in the previous commit.
>
> Signed-off-by: Jonathon Jongsma 

lgtm,
Reviewed-by: Marc-André Lureau 


> ---
>  src/qemu/qemu_command.c   | 21 ++-
>  src/qemu/qemu_monitor_json.c  | 28 -
>  src/qemu/qemu_validate.c  | 10 +++-
>  ...l-qemu-vdagent-features.x86_64-latest.args | 41 +
>  .../channel-qemu-vdagent-features.xml | 37 
>  .../channel-qemu-vdagent.x86_64-latest.args   | 41 +
>  .../qemuxml2argvdata/channel-qemu-vdagent.xml | 37 
>  tests/qemuxml2argvtest.c  |  2 +
>  ...el-qemu-vdagent-features.x86_64-latest.xml | 58 +++
>  .../channel-qemu-vdagent.x86_64-latest.xml| 58 +++
>  tests/qemuxml2xmltest.c   |  2 +
>  11 files changed, 332 insertions(+), 3 deletions(-)
>  create mode 100644 
> tests/qemuxml2argvdata/channel-qemu-vdagent-features.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent-features.xml
>  create mode 100644 
> tests/qemuxml2argvdata/channel-qemu-vdagent.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/channel-qemu-vdagent-features.x86_64-latest.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/channel-qemu-vdagent.x86_64-latest.xml
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 1eef9fb6d0..67921229dd 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -1389,8 +1389,27 @@ qemuBuildChardevStr(const virDomainChrSourceDef *dev,
>dev->data.spiceport.channel);
>  break;
>
> -case VIR_DOMAIN_CHR_TYPE_NMDM:
>  case VIR_DOMAIN_CHR_TYPE_QEMU_VDAGENT:
> +virBufferAsprintf(, "qemu-vdagent,id=%s,name=vdagent",
> +  charAlias);
> +if (dev->data.qemuVdagent.clipboard != VIR_TRISTATE_BOOL_ABSENT)
> +virBufferAsprintf(, ",clipboard=%s",
> +  
> virTristateSwitchTypeToString(dev->data.qemuVdagent.clipboard));
> +switch (dev->data.qemuVdagent.mouse) {
> +case VIR_DOMAIN_MOUSE_MODE_CLIENT:
> +virBufferAddLit(, ",mouse=on");
> +break;
> +case VIR_DOMAIN_MOUSE_MODE_SERVER:
> +virBufferAddLit(, ",mouse=off");
> +break;
> +case VIR_DOMAIN_MOUSE_MODE_DEFAULT:
> +case VIR_DOMAIN_MOUSE_MODE_LAST:
> +default:
> +break;
> +}
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_NMDM:
>  case VIR_DOMAIN_CHR_TYPE_LAST:
>  default:
>  break;
> diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
> index 1ac5377449..c7e18073c2 100644
> --- a/src/qemu/qemu_monitor_json.c
> +++ b/src/qemu/qemu_monitor_json.c
> @@ -6814,11 +6814,37 @@ qemuMonitorJSONAttachCharDevGetProps(const char 
> *chrID,
>
>  break;
>
> +case VIR_DOMAIN_CHR_TYPE_QEMU_VDAGENT: {
> +virTristateBool mouse = VIR_TRISTATE_BOOL_ABSENT;
> +switch (chr->data.qemuVdagent.mouse) {
> +case VIR_DOMAIN_MOUSE_MODE_CLIENT:
> +mouse = VIR_TRISTATE_BOOL_YES;
> +break;
> +case VIR_DOMAIN_MOUSE_MODE_SERVER:
> +mouse = VIR_TRISTATE_BOOL_NO;
> +break;
> +case VIR_DOMAIN_MOUSE_MODE_DEFAULT:
> +break;
> +case VIR_DOMAIN_MOUSE_MODE_LAST:
> +default:
> +virReportEnumRangeError(virDomainMouseMode,
> +chr->data.qemuVdagent.mouse);
> +return NULL;
> +}
> +backendType = "qemu-vdagent";
> +
> +if (virJSONValueObjectAdd(,
> +  "T:clipboard", 
> chr->data.qemuVdagent.clipboard,
> +  "T:mouse", mouse,
> +  NULL) < 0)
> +return NULL;
> +break;
> +}
> +
>  case VIR_DOMAIN_CHR_TYPE_SPICEPORT:
>  case VIR_DOMAIN_CHR_TYPE_PIPE:
>  case VIR_DOMAIN_CHR_TYPE_STDIO:
>  case VIR_DOMAIN_CHR_TYPE_NMDM:
> -case VIR_DOMAIN_CHR_TYPE_QEMU_VDAGENT:
>  virReportError(VIR_ERR_OPERATION_FAILED,
> _("Hotplug unsupported for char device type '%s'"),
>   

Re: [libvirt PATCH v2 3/4] conf: add qemu-vdagent channel

[Marc-André Lureau]

Hi


On Thu, Mar 24, 2022 at 11:26 PM Jonathon Jongsma  wrote:
>
> Add the ability to configure a qemu-vdagent in guest domains. This
> device is similar to the spice vdagent channel except that qemu handles
> the spice-vdagent protocol messages itself rather than routing them over
> a spice protocol channel.
>
> The qemu-vdagent device has two notable configuration options which
> determine whether qemu will handle particular vdagent features:
> 'clipboard' and 'mouse'.
>
> The 'clipboard' option allows qemu to synchronize its internal clipboard
> manager with the guest clipboard, which enables client<->guest clipboard
> synchronization for non-spice guests such as vnc.
>
> The 'mouse' option allows absolute mouse positioning to be sent over the
> vdagent channel rather than using a usb or virtio tablet device.
>
> Sample configuration:
>   
> 
> 
>   
>   
> 
>   
>
> Signed-off-by: Jonathon Jongsma 

I guess you could have added some domain XML tests here, but the next
patch covers it, so

Reviewed-by: Marc-André Lureau 

> ---
>  docs/formatdomain.rst | 23 
>  src/conf/domain_conf.c| 62 ++-
>  src/conf/domain_conf.h| 20 ++
>  src/conf/domain_validate.c|  1 +
>  src/conf/schemas/domaincommon.rng | 51 -
>  src/qemu/qemu_command.c   |  3 ++
>  src/qemu/qemu_monitor_json.c  |  1 +
>  src/qemu/qemu_process.c   |  1 +
>  src/qemu/qemu_validate.c  |  1 +
>  src/security/security_apparmor.c  |  2 +
>  src/security/security_dac.c   |  2 +
>  tests/testutilsqemu.c |  1 +
>  12 files changed, 140 insertions(+), 28 deletions(-)
>
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index e492532004..75339c2fda 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -6662,6 +6662,29 @@ types have different ``target`` attributes.
> ``name='com.redhat.spice.0'``. The optional ``address`` element can tie 
> the
> channel to a particular ``type='virtio-serial'`` controller. :since:`Since
> 0.8.8`
> +``qemu-vdagent``
> +   Paravirtualized qemu vdagent channel. This channel implements the SPICE
> +   vdagent protocol, but is handled internally by qemu and therefore does not
> +   require a SPICE graphics device. Like the spicevmc channel, the ``target``
> +   element must be present, with attribute ``type='virtio'``; an optional
> +   attribute ``name`` controls how the guest will have access to the channel,
> +   and defaults to ``name='com.redhat.spice.0'``. The optional ``address``
> +   element can tie the channel to a particular ``type='virtio-serial'``
> +   controller. Certain vdagent protocol features can by enabled or disabled
> +   using the ``source`` element.
> +
> +   Copy & Paste functionality is set by the ``clipboard`` element. It is
> +   disabled by default, and can be enabled by setting the ``copypaste``
> +   property to ``yes``. This allows the guest's clipboard to be synchronized
> +   with the qemu clipboard manager. This can enable copy and paste between a
> +   guest and a client when using a VNC `graphics device 
> <#elementsGraphics>`__
> +   (when using a VNC client that supports the copy/paste feature) or other
> +   graphics types that support the qemu clipboard manager.
> +
> +   Mouse mode is set by the ``mouse`` element, setting its ``mode`` attribute
> +   to one of ``server`` or ``client``. If no mode is specified, the qemu
> +   default will be used (client mode).
> +   :since:`Since 8.2.0`
>
>  :anchor:``
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 6f9954638c..3b97de89f4 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -713,6 +713,7 @@ VIR_ENUM_IMPL(virDomainChr,
>"spicevmc",
>"spiceport",
>"nmdm",
> +  "qemu-vdagent",
>  );
>
>  VIR_ENUM_IMPL(virDomainChrTcpProtocol,
> @@ -2698,6 +2699,7 @@ virDomainChrSourceDefGetPath(virDomainChrSourceDef *chr)
>  case VIR_DOMAIN_CHR_TYPE_STDIO:
>  case VIR_DOMAIN_CHR_TYPE_SPICEVMC:
>  case VIR_DOMAIN_CHR_TYPE_SPICEPORT:
> +case VIR_DOMAIN_CHR_TYPE_QEMU_VDAGENT:
>  case VIR_DOMAIN_CHR_TYPE_LAST:
>  return NULL;
>  }
> @@ -2807,6 +2809,11 @@ virDomainChrSourceDefCopy(virDomainChrSourceDef *dest,
>  dest->data.spiceport.channel = g_strdup(src->data.spiceport.channel);
>  break;
>
> +case VIR_DOMAIN_CHR_TYPE_QEMU_VDAGENT:
> +dest->data.qemuVdagent.clipboard = src->data.qemuVdagent.clipbo

Re: [libvirt PATCH v2 2/4] Rename virDomainGraphicsSpiceMouseMode to virDomainMouseMode

[Marc-André Lureau]

On Thu, Mar 24, 2022 at 11:26 PM Jonathon Jongsma  wrote:
>
> This enumeration will be useful for vnc with the upcoming qemu-vdagent
> device so make the name more generic.
>
> Signed-off-by: Jonathon Jongsma 

Reviewed-by: Marc-André Lureau 

> ---
>  src/conf/domain_conf.c   |  8 
>  src/conf/domain_conf.h   | 14 +++---
>  src/libvirt_private.syms |  4 ++--
>  src/libxl/libxl_conf.c   |  8 
>  src/libxl/xen_xl.c   | 16 +++-
>  src/qemu/qemu_command.c  | 10 +-
>  6 files changed, 29 insertions(+), 31 deletions(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 731139f80f..6f9954638c 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -995,8 +995,8 @@ VIR_ENUM_IMPL(virDomainGraphicsSpiceZlibCompression,
>"always",
>  );
>
> -VIR_ENUM_IMPL(virDomainGraphicsSpiceMouseMode,
> -  VIR_DOMAIN_GRAPHICS_SPICE_MOUSE_MODE_LAST,
> +VIR_ENUM_IMPL(virDomainMouseMode,
> +  VIR_DOMAIN_MOUSE_MODE_LAST,
>"default",
>"server",
>"client",
> @@ -12727,7 +12727,7 @@ 
> virDomainGraphicsDefParseXMLSpice(virDomainGraphicsDef *def,
>
>  if ((cur = virXPathNode("./mouse", ctxt))) {
>  if (virXMLPropEnum(cur, "mode",
> -   virDomainGraphicsSpiceMouseModeTypeFromString,
> +   virDomainMouseModeTypeFromString,
> VIR_XML_PROP_REQUIRED | VIR_XML_PROP_NONZERO,
> >data.spice.mousemode) < 0)
>  return -1;
> @@ -26616,7 +26616,7 @@ virDomainGraphicsDefFormat(virBuffer *buf,
>
> virDomainGraphicsSpiceStreamingModeTypeToString(def->data.spice.streaming));
>  if (def->data.spice.mousemode)
>  virBufferAsprintf(buf, "\n",
> -  
> virDomainGraphicsSpiceMouseModeTypeToString(def->data.spice.mousemode));
> +  
> virDomainMouseModeTypeToString(def->data.spice.mousemode));
>  if (def->data.spice.copypaste)
>  virBufferAsprintf(buf, "\n",
>
> virTristateBoolTypeToString(def->data.spice.copypaste));
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index 49c964e6e1..2b00099431 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -1844,12 +1844,12 @@ typedef enum {
>  } virDomainGraphicsSpiceZlibCompression;
>
>  typedef enum {
> -VIR_DOMAIN_GRAPHICS_SPICE_MOUSE_MODE_DEFAULT = 0,
> -VIR_DOMAIN_GRAPHICS_SPICE_MOUSE_MODE_SERVER,
> -VIR_DOMAIN_GRAPHICS_SPICE_MOUSE_MODE_CLIENT,
> +VIR_DOMAIN_MOUSE_MODE_DEFAULT = 0,
> +VIR_DOMAIN_MOUSE_MODE_SERVER,
> +VIR_DOMAIN_MOUSE_MODE_CLIENT,
>
> -VIR_DOMAIN_GRAPHICS_SPICE_MOUSE_MODE_LAST
> -} virDomainGraphicsSpiceMouseMode;
> +VIR_DOMAIN_MOUSE_MODE_LAST
> +} virDomainMouseMode;
>
>  typedef enum {
>  VIR_DOMAIN_GRAPHICS_SPICE_STREAMING_MODE_DEFAULT = 0,
> @@ -1927,7 +1927,7 @@ struct _virDomainGraphicsDef {
>  int tlsPort;
>  bool portReserved;
>  bool tlsPortReserved;
> -virDomainGraphicsSpiceMouseMode mousemode;
> +virDomainMouseMode mousemode;
>  char *keymap;
>  virDomainGraphicsAuthDef auth;
>  bool autoport;
> @@ -3990,7 +3990,7 @@ VIR_ENUM_DECL(virDomainGraphicsSpiceImageCompression);
>  VIR_ENUM_DECL(virDomainGraphicsSpiceJpegCompression);
>  VIR_ENUM_DECL(virDomainGraphicsSpiceZlibCompression);
>  VIR_ENUM_DECL(virDomainGraphicsSpiceStreamingMode);
> -VIR_ENUM_DECL(virDomainGraphicsSpiceMouseMode);
> +VIR_ENUM_DECL(virDomainMouseMode);
>  VIR_ENUM_DECL(virDomainGraphicsVNCSharePolicy);
>  VIR_ENUM_DECL(virDomainHyperv);
>  VIR_ENUM_DECL(virDomainKVM);
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 03697d81a8..400adf14b5 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -444,8 +444,6 @@ virDomainGraphicsSpiceImageCompressionTypeFromString;
>  virDomainGraphicsSpiceImageCompressionTypeToString;
>  virDomainGraphicsSpiceJpegCompressionTypeFromString;
>  virDomainGraphicsSpiceJpegCompressionTypeToString;
> -virDomainGraphicsSpiceMouseModeTypeFromString;
> -virDomainGraphicsSpiceMouseModeTypeToString;
>  virDomainGraphicsSpiceStreamingModeTypeFromString;
>  virDomainGraphicsSpiceStreamingModeTypeToString;
>  virDomainGraphicsSpiceZlibCompressionTypeFromString;
> @@ -519,6 +517,8 @@ virDomainMemoryModelTypeToStri

Re: [libvirt PATCH v2 1/4] qemu: add capability for qemu-vdagent chardev

[Marc-André Lureau]

On Thu, Mar 24, 2022 at 11:26 PM Jonathon Jongsma  wrote:
>
> Detect whether qemu supports the qemu-vdagent character device. This
> enables support for copy/paste with VNC graphics.
>
> Signed-off-by: Jonathon Jongsma 

Reviewed-by: Marc-André Lureau 

> ---
>  src/qemu/qemu_capabilities.c  | 2 ++
>  src/qemu/qemu_capabilities.h  | 1 +
>  tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml  | 1 +
>  tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 +
>  tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml  | 1 +
>  tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml  | 1 +
>  6 files changed, 7 insertions(+)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 6b4ed08499..f31e7395c3 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -669,6 +669,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
>/* 425 */
>"blockdev.nbd.tls-hostname", /* 
> QEMU_CAPS_BLOCKDEV_NBD_TLS_HOSTNAME */
>"memory-backend-file.prealloc-threads", /* 
> QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS */
> +  "chardev.qemu-vdagent", /* QEMU_CAPS_CHARDEV_QEMU_VDAGENT */
>  );
>
>
> @@ -1629,6 +1630,7 @@ static struct virQEMUCapsStringFlags 
> virQEMUCapsQMPSchemaQueries[] = {
>  { "set-numa-node/arg-type/+hmat-lb", QEMU_CAPS_NUMA_HMAT },
>  { "object-add/arg-type/+sev-guest/kernel-hashes", 
> QEMU_CAPS_SEV_GUEST_KERNEL_HASHES },
>  { "calc-dirty-rate/arg-type/mode", QEMU_CAPS_DIRTYRATE_MODE },
> +{ "chardev-add/arg-type/backend/+qemu-vdagent", 
> QEMU_CAPS_CHARDEV_QEMU_VDAGENT },
>  };
>
>  typedef struct _virQEMUCapsObjectTypeProps virQEMUCapsObjectTypeProps;
> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> index 948029d60d..f5a9609b8c 100644
> --- a/src/qemu/qemu_capabilities.h
> +++ b/src/qemu/qemu_capabilities.h
> @@ -644,6 +644,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for 
> syntax-check */
>  /* 425 */
>  QEMU_CAPS_BLOCKDEV_NBD_TLS_HOSTNAME, /* tls hostname can be overriden 
> for NBD clients */
>  QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS, /* -object 
> memory-backend-*.prealloc-threads */
> +QEMU_CAPS_CHARDEV_QEMU_VDAGENT, /* -chardev qemu-vdagent */
>
>  QEMU_CAPS_LAST /* this must always be the last item */
>  } virQEMUCapsFlags;
> diff --git a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml 
> b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
> index 0b58210335..fceb7dbea6 100644
> --- a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
> +++ b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
> @@ -240,6 +240,7 @@
>
>
>
> +  
>6001000
>0
>43100243
> diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml 
> b/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
> index d08b2c0213..6a5c39a0de 100644
> --- a/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
> +++ b/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
> @@ -204,6 +204,7 @@
>
>
>
> +  
>6001050
>0
>61700244
> diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml 
> b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
> index cdf72b9ebf..6f4fa26808 100644
> --- a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
> +++ b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
> @@ -242,6 +242,7 @@
>
>
>
> +  
>6002000
>0
>43100244
> diff --git a/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml 
> b/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
> index 5227e3ee0b..8219347f2a 100644
> --- a/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
> +++ b/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
> @@ -245,6 +245,7 @@
>
>
>
> +  
>6002050
>0
>43100243
> --
> 2.35.1
>

Re: [libvirt PATCH 0/3] Enable copy/paste for vnc displays

[Marc-André Lureau]

Hi

On Wed, Mar 23, 2022 at 6:44 PM Jonathon Jongsma  wrote:
>
> On 3/23/22 4:17 AM, Daniel P. Berrangé wrote:
> > On Wed, Mar 23, 2022 at 12:01:19PM +0400, Marc-André Lureau wrote:
> >> Hi
> >>
> >> On Wed, Mar 23, 2022 at 12:47 AM Jonathon Jongsma  
> >> wrote:
> >>>
> >>> This patch series enables support for the qemu-vdagent character device 
> >>> which
> >>> enables copy/paste support between guest and client when using vnc 
> >>> graphics.
> >>>
> >>> The guest must be configured with something like the following:
> >>>
> >>>  
> >>>
> >>>
> >>>  
> >>>
> >>> Copy/paste sync requires a vnc client that has support for copy/paste 
> >>> commands.
> >>> Currently virt-viewer does not work, but the version of tigervnc provided 
> >>> by
> >>> fedora (executable name 'vncviewer') does work.
> >>>
> >>> More details about this device on Gerd's blog:
> >>> https://www.kraxel.org/blog/2021/05/qemu-cut-paste/
> >>>
> >>> OPEN QUESTIONS:
> >>>
> >>> - I'm not fully convinced that the `` element is the right place 
> >>> for
> >>>the new `clipboard` / `mouse` configuration options, but I'm not sure 
> >>> that
> >>>adding a new xml element to the `` is the right approach 
> >>> either.
> >>>Suggestions welcome.
> >>
> >> I am not convinced  is appropriate either for -chardev
> >> qemu-vdagent. That's why in my dbus display series it's an
> >> implementation detail
> >> (https://patchew.org/Libvirt/20211222194345.766352-1-marcandre.lur...@redhat.com/20211222194345.766352-13-marcandre.lur...@redhat.com/),
> >> and it's not exposed to the domain XML directly. However I realize
> >> that my approach is probably broken, as it looks like I totally missed
> >> the associated virtserialport! :)
> >>
> >> As you say "source" is strange to put those extra channel options too.
> >>
> >> And the only really valid associated device is a virtserialport of
> >> name "com.redhat.spice.0", so what's the point in exposing that detail
> >> to the user?
>
> You could say the same thing about the normal spice vdagent, right? And
> we allow the user to specify a different virtio name for the spicevmc

Yes, although the spicevmc -chardev can is configurable via its name
to transport various content, whereas qemu-vdagent is limited to
spice-vdagent.

> channel. spice-vdagent does offer a --virtio-serial-port-path option
> that can be used to connect to a different name within the guest, after all.

Oh my, it's probably a good idea to deprecate it.

>
> >
> > At the QEMU level we have one serial port with chardv
> >
> >-chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on
> >-device virtio-serial-pci \
> >-device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0
> >
> >
> > but IIUC, we can have multiple frontends - ie both VNC and DBus
> > display, and in that case the clipboard=on property on the
> > chardev will apply to both VNC & DBus displays. We can't
> > control clipboard independantly for the displays, so it is
> > right to put the control in the XML for the  for
> > both VNC and DBus.
> >
>
> In addition to , there are several other xml elements that
> essentially map to a qemu character device: , , etc.
> Would it make more sense to introduce a new element like this for the
> qemu-vdagent? This might make it easier to introduce new configuration
> options that wouldn't really fit in the general . For example,
> something like:
>
> 
>
>
> 
>
> Jonathon
>

Re: [libvirt PATCH 0/3] Enable copy/paste for vnc displays

[Marc-André Lureau]

Hi

On Wed, Mar 23, 2022 at 12:47 AM Jonathon Jongsma  wrote:
>
> This patch series enables support for the qemu-vdagent character device which
> enables copy/paste support between guest and client when using vnc graphics.
>
> The guest must be configured with something like the following:
>
> 
>   
>   
> 
>
> Copy/paste sync requires a vnc client that has support for copy/paste 
> commands.
> Currently virt-viewer does not work, but the version of tigervnc provided by
> fedora (executable name 'vncviewer') does work.
>
> More details about this device on Gerd's blog:
> https://www.kraxel.org/blog/2021/05/qemu-cut-paste/
>
> OPEN QUESTIONS:
>
> - I'm not fully convinced that the `` element is the right place for
>   the new `clipboard` / `mouse` configuration options, but I'm not sure that
>   adding a new xml element to the `` is the right approach either.
>   Suggestions welcome.

I am not convinced  is appropriate either for -chardev
qemu-vdagent. That's why in my dbus display series it's an
implementation detail
(https://patchew.org/Libvirt/20211222194345.766352-1-marcandre.lur...@redhat.com/20211222194345.766352-13-marcandre.lur...@redhat.com/),
and it's not exposed to the domain XML directly. However I realize
that my approach is probably broken, as it looks like I totally missed
the associated virtserialport! :)

As you say "source" is strange to put those extra channel options too.

And the only really valid associated device is a virtserialport of
name "com.redhat.spice.0", so what's the point in exposing that detail
to the user?

> - There may be an expectation that vnc clipboard is enabled using the
>similar to what
>   spice offers. In fact, it seems that this is the approach Marc-Andre took
>   when adding copy/paste support in his dbus display patch series. But even 
> for
>   spice, this  configuration element is not enough to enable the
>   copy/paste feature. It also requires a 'spicevmc' character device to be
>   added to the domain.

And my dbus solution is not complete, although it should be possible
to add the missing virtserialport.

>
> Jonathon Jongsma (3):
>   qemu: add capability for qemu-vdagent chardev
>   conf: add qemu-vdagent channel
>   qemu: add support for qemu-vdagent channel
>
>  docs/formatdomain.rst | 17 ++
>  src/conf/domain_conf.c| 49 -
>  src/conf/domain_conf.h|  7 +++
>  src/conf/domain_validate.c|  1 +
>  src/conf/schemas/domaincommon.rng | 11 
>  src/qemu/qemu_capabilities.c  |  2 +
>  src/qemu/qemu_capabilities.h  |  1 +
>  src/qemu/qemu_command.c   | 13 +
>  src/qemu/qemu_monitor_json.c  | 10 
>  src/qemu/qemu_process.c   |  1 +
>  src/qemu/qemu_validate.c  |  1 +
>  src/security/security_dac.c   |  2 +
>  .../caps_6.1.0.x86_64.xml |  1 +
>  .../caps_6.2.0.aarch64.xml|  1 +
>  .../caps_6.2.0.x86_64.xml |  1 +
>  .../caps_7.0.0.x86_64.xml |  1 +
>  .../channel-qemu-vdagent.x86_64-latest.args   | 41 ++
>  .../qemuxml2argvdata/channel-qemu-vdagent.xml | 34 
>  tests/qemuxml2argvtest.c  |  1 +
>  .../channel-qemu-vdagent.x86_64-latest.xml| 55 +++
>  tests/qemuxml2xmltest.c   |  1 +
>  tests/testutilsqemu.c |  1 +
>  22 files changed, 250 insertions(+), 2 deletions(-)
>  create mode 100644 
> tests/qemuxml2argvdata/channel-qemu-vdagent.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/channel-qemu-vdagent.x86_64-latest.xml
>
> --
> 2.35.1
>
>

Re: [PATCH v2 2/7] vircommand: Document virCommandSetSendBuffer() behaviour wrt daemonize

[Marc-André Lureau]

Hi

On Tue, Mar 22, 2022 at 8:02 PM Michal Privoznik 
wrote:

> When virCommandSetSendBuffer() is used over a virCommand that is
> (or will be) daemonized, then VIR_EXEC_ASYNC_IO the command must
> have VIR_EXEC_ASYNC_IO flag set no later than at
> virCommandRunAsync() phase so that the thread that's doing IO is
> spawned and thus buffers can be sent to the process.
>
> Signed-off-by: Michal Privoznik 
> ---
>  src/util/vircommand.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 41cf552d7b..5f22bd0ac3 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -1719,6 +1719,9 @@ virCommandFreeSendBuffers(virCommand *cmd)
>   * @buffer is always stolen regardless of the return value. This function
>   * doesn't raise a libvirt error, but rather propagates the error via
> virCommand.
>   * Thus callers don't need to take a special action if -1 is returned.
> + *
> + * When the @cmd is daemonized via virCommandDaemonize() remember to
> request
> + * asynchronous IO via virCommandDoAsyncIO().
>

Or else the RunAsync() should return an error, no?

Why not call DoAsyncIO() implicitly in RunAsync() in this case?

(sorry to repeat maybe my earlier question, trying to be more precise :)

thanks

-- 
Marc-André Lureau

Re: [PATCH] qemu_tpm: Do async IO when starting swtpm emulator

[Marc-André Lureau]

Hi

On Mon, Mar 21, 2022 at 6:59 PM Michal Privoznik 
wrote:

> When vTPM is secured via virSecret libvirt passes the secret
> value via an FD when swtpm is started (arguments --key and
> --migration-key). The writing of the secret into the FDs is
> handled via virCommand, specifically qemu_tpm calls
> virCommandSetSendBuffer()) and then virCommandRunAsync() spawns a
> thread to handle writing into the FD via
> virCommandDoAsyncIOHelper. But the thread is not created unless
> VIR_EXEC_ASYNC_IO flag is set, which it isn't. In order to fix
> it, virCommandDoAsyncIO() must be called.
>
> The credit goes to Marc-André Lureau
>  who has done all the debugging and
> proposed fix in the bugzilla.
>

(thanks for the credit :)

Wouldn't it make sense to return an error if SendBuffers is used without
AsyncIO then? Or just enable AsyncIO as necessary? (beware, I am not very
familiar with virCommand API. I don't know what this would imply)

Also it would be nice to cover that "behaviour" in a test (even better if
we could cover the swtpm setup & start handling too, although I realize
this is more work!)


> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2064115
> Fixes: a9c500d2b50c5c041a1bb6ae9724402cf1cec8fe
> Signed-off-by: Michal Privoznik 
> ---
>  src/qemu/qemu_tpm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 50f9caabf3..56bccee128 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -899,6 +899,7 @@ qemuTPMEmulatorStart(virQEMUDriver *driver,
>  if (!(pidfile = qemuTPMEmulatorPidFileBuildPath(cfg->swtpmStateDir,
> shortName)))
>  return -1;
>
> +virCommandDoAsyncIO(cmd);
>  virCommandDaemonize(cmd);
>  virCommandSetPidFile(cmd, pidfile);
>  virCommandSetErrorFD(cmd, );
> --
> 2.34.1
>
>

-- 
Marc-André Lureau

Re: [libvirt PATCH v3 00/16] Add QEMU "-display dbus" support

[Marc-André Lureau]

Hi Neal

On Fri, Dec 31, 2021 at 6:09 AM Neal Gompa  wrote:
>
> On Wed, Dec 22, 2021 at 2:44 PM  wrote:
> >
> > From: Marc-André Lureau 
> >
> > Hi,
> >
> > This series implements supports for the uQEMU "-display dbus" support, that
> > landed earlier this week for 7.0.
> >
> > By default, libvirt will start a private VM bus (sharing and reusing the
> > existing "vmstate" VM bus & code).
> >
> > The feature set should cover the needs to replace Spice as local client of 
> > choice,
> > including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and 
> > arbitrary
> > chardev/channels (for serial etc).
> >
> > The test Gtk4 client is also in progress, currently in development at
> > https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such 
> > as
> > zbus, require an upcoming release. virt-viewer & boxes will need a port to 
> > Gtk4
> > to make use of the shared widget.
> >
> > Comments welcome, as we can still adjust the QEMU side etc.
> >
> > thanks
> >
> > v3: after QEMU 7.0 dev cycle opening and merge
> >  - rebased
> >  - add 7.0 x86-64 capabilities (instead of tweaking 6.2)
> >  - fix version annotations
> >
> > Marc-André Lureau (16):
> >   qemu: add chardev-vdagent capability check
> >   qemu: add -display dbus capability check
> >   qemucapabilitiestest: Add x64 test data for the qemu-7.0 development
> > cycle
> >   conf: add 
> >   qemu: start the D-Bus daemon for the display
> >   qemu: add -display dbus support
> >   virsh: refactor/split cmdDomDisplay()
> >   virsh: report the D-Bus bus URI for domdisplay
> >   conf: add  support
> >   qemu: add audio type 'dbus'
> >   conf: add dbus 
> >   qemu: add dbus clipboard sharing
> >   conf: add 
> >   qemu: add -chardev dbus support
> >   qemu: add usbredir type 'dbus'
> >   docs: document  type dbus
> >
> >  NEWS.rst  | 7 +-
> >  docs/formatdomain.rst |43 +-
> >  docs/schemas/basictypes.rng   | 7 +
> >  docs/schemas/domaincommon.rng |71 +
> >  src/bhyve/bhyve_command.c | 1 +
> >  src/conf/domain_conf.c|   141 +-
> >  src/conf/domain_conf.h|15 +
> >  src/conf/domain_validate.c|41 +-
> >  src/libxl/libxl_conf.c| 1 +
> >  src/qemu/qemu_capabilities.c  | 8 +
> >  src/qemu/qemu_capabilities.h  | 4 +
> >  src/qemu/qemu_command.c   |77 +-
> >  src/qemu/qemu_domain.c| 1 +
> >  src/qemu/qemu_driver.c|10 +-
> >  src/qemu/qemu_extdevice.c |13 +
> >  src/qemu/qemu_hotplug.c   | 1 +
> >  src/qemu/qemu_monitor_json.c  |10 +
> >  src/qemu/qemu_process.c   |41 +-
> >  src/qemu/qemu_validate.c  |33 +
> >  src/security/security_dac.c   | 2 +
> >  src/vmx/vmx.c | 1 +
> >  .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  |   231 +
> >  .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  |   237 +
> >  tests/domaincapsdata/qemu_7.0.0.x86_64.xml|   231 +
> >  .../caps_6.1.0.x86_64.xml | 1 +
> >  .../caps_6.2.0.aarch64.xml| 1 +
> >  .../caps_6.2.0.x86_64.xml | 1 +
> >  .../caps_7.0.0.x86_64.replies | 37335 
> >  .../caps_7.0.0.x86_64.xml |  3720 ++
> >  .../graphics-dbus-address.args|30 +
> >  .../graphics-dbus-address.xml |35 +
> >  .../qemuxml2argvdata/graphics-dbus-audio.args |33 +
> >  .../qemuxml2argvdata/graphics-dbus-audio.xml  |45 +
> >  .../graphics-dbus-chardev.args|32 +
> >  .../graphics-dbus-chardev.xml |43 +
> >  .../graphics-dbus-clipboard.args  |31 +
> >  .../graphics-dbus-clipboard.xml   |35 +
> >  tests/qemuxml2argvdata/graphics-dbus-p2p.args |30 +
> >  tests/qemuxml2argvdata/graphics-dbus-p2p.xml  |33 +
> >  .../graphics-dbus-usbredir.args   |34 +
> >  .../graphics-dbus-usbredir.xml|30 +
> >  tests/qemuxml2argvdata/graphics-

Re: [libvirt PATCH v2 00/15] WIP/RFC: add QEMU "-display dbus" support

[Marc-André Lureau]

Hi

On Fri, Dec 3, 2021 at 8:29 PM Daniel P. Berrangé  wrote:
>
> On Thu, Dec 02, 2021 at 06:23:56PM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Hi,
> >
> > This series implements supports for the upcoming QEMU "-display dbus" 
> > support.
> > Development is still in progress, but I hope to land the QEMU support early 
> > in
> > 6.3 (last version posted:
> > https://patchew.org/QEMU/20211009210838.2219430-1-marcandre.lur...@redhat.com/).
> >
> > By default, libvirt will start a private VM bus (sharing and reusing the
> > existing "vmstate" VM bus & code).
> >
> > The feature set should cover the needs to replace Spice as local client of 
> > choice,
> > including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and 
> > arbitrary
> > chardev/channels (for serial etc).
> >
> > The test Gtk4 client is also in progress, currently in development at
> > https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such 
> > as
> > zbus, require an upcoming release. virt-viewer & boxes will need a port to 
> > Gtk4
> > to make use of the shared widget.
>
> How is this intended to work permissions wise ?
>
> For the qemu:///session instance, everything is running the same user
> account, so its fairly easy.
>
> For the qemu:///system instance, the VM's private dbus-daemon bus will be
> running under a qemu:qemu user account, while the user wishing to have a
> client window will be a completely different account. How will the Gtk4
> client get permission to connect to dbus-daemon ?

Tbh, I haven't tried system instance yet! The per-vm bus needs to
allow user connections (just like the dbus system bus).

I'll add this to my todo/tocheck list for the next iteration.

> Also what are the long term implications for the rest of the QEMU builtin
> display backends ?
>
> It feels like all of VNC, SPICE, SDL and GTK backends that are currently
> run in the main QEMU process, could be split off to be separate programs
> using dbus.

Yes, I even started a VNC server
(https://gitlab.com/marcandre.lureau/qemu-display/-/tree/master/qemu-vnc),
although it's really a toy compared to qemu implementation at this
point.

I would rather focus on an RDP server though.

>
> Libvirt currently represents each fo these backenjds as a 
> type, and I think we'd want to continue to use that syntax even if they
> were separate processes.
>
> ie, i would want something more like
>
>
>   
>
>
> to request that libvirt spawn a SPICE server, connecting over dbus
> vs built-in. Likewise for the other options.
>
> IOW, do we actually want to expose type="dbus" as a concept long term,
> or are we better off just having it as an internal impl detail ?

If we can make it an internal impl detail, that would be great (like
we did for slirp-helper - even if nobody really uses it ;)

>
> Of course we would actually need the dbus clients to exist first...

Yes, it will take a while to get there.

Re: [libvirt PATCH 1/9] qemu: start the D-Bus daemon as needed

[Marc-André Lureau]

On Mon, Nov 29, 2021 at 9:20 PM Michal Prívozník  wrote:
>
> On 11/5/21 11:51, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > The daemon is started on daemon in external devices and hotplug code.
> > Add a mechanism to start it before qemu, if qemu itself needs it. (it is
> > already stopped in qemuProcessStop)
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  src/qemu/qemu_domain.h  | 1 +
> >  src/qemu/qemu_process.c | 4 
> >  2 files changed, 5 insertions(+)
> >
> > diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
> > index 6728ab047ed0..575fb8393b83 100644
> > --- a/src/qemu/qemu_domain.h
> > +++ b/src/qemu/qemu_domain.h
> > @@ -237,6 +237,7 @@ struct _qemuDomainObjPrivate {
> >  /* running backup job */
> >  virDomainBackupDef *backup;
> >
> > +bool dbusDaemonWanted;
> >  bool dbusDaemonRunning;
> >
> >  /* list of Ids to migrate */
> > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> > index d5f8a47ac293..4ca9b100a802 100644
> > --- a/src/qemu/qemu_process.c
> > +++ b/src/qemu/qemu_process.c
> > @@ -7284,6 +7284,10 @@ qemuProcessLaunch(virConnectPtr conn,
> >   , , 0)))
> >  goto cleanup;
> >
> > +if (QEMU_DOMAIN_PRIVATE(vm)->dbusDaemonWanted &&
> > +qemuDBusStart(driver, vm) < 0)
> > +goto cleanup;
> > +
>
> We already have priv variable, so s/QEMU_DOMAIN_PRIVATE(vm)/priv/.
> However, we already have qemuExtDevicesStart() which I believe can be
> used to check whether dbus graphics was defined and thus whether dbus
> daemon needs to be started.

indeed, done.
thanks

>
>
> >  if (incoming && incoming->fd != -1)
> >  virCommandPassFD(cmd, incoming->fd, 0);
> >
> >
>
> Michal
>

Re: [libvirt PATCH 4/9] qemu: add -display dbus support

[Marc-André Lureau]

Hi

On Mon, Nov 29, 2021 at 9:20 PM Michal Prívozník  wrote:
>
> On 11/5/21 11:51, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Without any extra option, libvirt will start and tell QEMU to connect to
> > the private VM bus.
> >
> > Instead, a D-Bus "address" to connect to can be specified. Or the p2p
> > mode enabled.
> >
> > D-Bus display best works with GL & a rendernode, which can be specified
> > with  child element.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  docs/schemas/basictypes.rng   |  7 ++
> >  docs/schemas/domaincommon.rng | 33 ++
> >  src/conf/domain_conf.c| 65 ++-
> >  src/conf/domain_conf.h|  7 ++
> >  src/libxl/libxl_conf.c|  1 +
> >  src/qemu/qemu_capabilities.c  |  2 +
> >  src/qemu/qemu_command.c   | 57 ++--
> >  src/qemu/qemu_domain.c|  1 +
> >  src/qemu/qemu_driver.c| 10 ++-
> >  src/qemu/qemu_hotplug.c   |  1 +
> >  src/qemu/qemu_process.c   | 11 +++-
> >  src/qemu/qemu_validate.c  |  1 +
> >  src/vmx/vmx.c |  1 +
> >  .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  |  1 +
> >  .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  |  1 +
> >  tests/domaincapsdata/qemu_6.2.0.x86_64.xml|  1 +
> >  .../graphics-dbus-address.args| 31 +
> >  .../graphics-dbus-address.xml | 34 ++
> >  tests/qemuxml2argvdata/graphics-dbus-p2p.args | 31 +
> >  tests/qemuxml2argvdata/graphics-dbus-p2p.xml  | 36 ++
> >  tests/qemuxml2argvdata/graphics-dbus.args | 31 +
> >  tests/qemuxml2argvdata/graphics-dbus.xml  | 34 ++
> >  tests/qemuxml2argvtest.c  |  7 ++
> >  .../graphics-dbus-address.xml | 39 +++
> >  .../qemuxml2xmloutdata/graphics-dbus-p2p.xml  | 39 +++
> >  tests/qemuxml2xmloutdata/graphics-dbus.xml| 39 +++
> >  tests/qemuxml2xmltest.c   | 10 +++
> >  27 files changed, 523 insertions(+), 8 deletions(-)
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.args
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.xml
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-p2p.args
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-p2p.xml
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus.args
> >  create mode 100644 tests/qemuxml2argvdata/graphics-dbus.xml
> >  create mode 100644 tests/qemuxml2xmloutdata/graphics-dbus-address.xml
> >  create mode 100644 tests/qemuxml2xmloutdata/graphics-dbus-p2p.xml
> >  create mode 100644 tests/qemuxml2xmloutdata/graphics-dbus.xml
>
> We like to separate changes to public structures (like XML and/or APIs)
> and changes to drviers. IOW, this should be split into two patches, in
> the first you include all XML related changes (parsing, formatting) can
> even introduce those .args files so that xml2xmltest can check XML
> parsing & formatting. In here, you can put 'case
> VIR_DOMAIN_GRAPHICS_TYPE_DBUS:' just next to
> 'VIR_DOMAIN_GRAPHICS_TYPE_LAST' so that using dbus type errors out. And
> then in the second patch you provide the qemu implementation.

Ok

>
>
> Oh, and don't forget to document your changes in docs/formatdomain.rst
> so that users know there's a new type and what attributes they can set.

It's the last patch. It can be squashed.

>
> >
> > diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng
> > index a221ff6295c0..ae4d5682229c 100644
> > --- a/docs/schemas/basictypes.rng
> > +++ b/docs/schemas/basictypes.rng
> > @@ -220,6 +220,13 @@
> >
> >
> > 
> >
> > +  
> > +  
> > +
> > +  .+
> > +
> > +  
>
> Or use "filePath&

Re: [libvirt PATCH 3/9] qemu: add -display dbus capability check (to update to 6.3)

[Marc-André Lureau]

Hi

On Tue, Nov 30, 2021 at 12:41 AM Peter Krempa  wrote:
>
> On Fri, Nov 05, 2021 at 14:51:13 +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  src/qemu/qemu_capabilities.c |  2 ++
> >  src/qemu/qemu_capabilities.h |  1 +
> >  tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies | 10 +-
> >  tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml |  1 +
> >  4 files changed, 13 insertions(+), 1 deletion(-)
>
> [...]
>
> > diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies 
> > b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies
> > index 69d3b1b12a6e..e823ad1188b8 100644
> > --- a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies
> > +++ b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies
> > @@ -5000,6 +5000,10 @@
> >  {
> >"case": "spice-app",
> >"type": "0"
> > +},
> > +{
> > +  "case": "dbus",
> > +  "type": "0"
> >  }
> >],
> >"members": [
> > @@ -11456,6 +11460,9 @@
> >  },
> >  {
> >"name": "spice-app"
> > +},
> > +{
> > +  "name": "dbus"
> >  }
> >],
> >"meta-type": "enum",
> > @@ -11465,7 +11472,8 @@
> >  "sdl",
> >  "egl-headless",
> >  "curses",
> > -"spice-app"
> > +"spice-app",
> > +"dbus"
>
> I didn't find this one in my latest re-generation of the capabilities
> from the current master. Do I need to enable/add some dependencies, or
> is this something that is not upstream yet? In case if it isn't upstream,
> these hunks are obviously not acceptable.
>

As explained on the cover letter, this series is WIP/RFC before I
propose a MR for qemu in early 6.3 (this month).

thanks

Re: [libvirt PATCH 0/9] WIP/RFC: add QEMU "-display dbus" support

[Marc-André Lureau]

Hi

On Fri, Nov 5, 2021 at 2:51 PM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> This series implements supports for the upcoming QEMU "-display dbus" support.
> Development is still in progress, but I hope to land the QEMU support early in
> 6.3 (last version posted:
> https://patchew.org/QEMU/20211009210838.2219430-1-marcandre.lur...@redhat.com/).
>
> By default, libvirt will start a private VM bus (sharing and reusing the
> existing "vmstate" code). A client will need the address of the bus and access
> to it. Since D-Bus addresses are not URIs unfortunately, I am not sure yet 
> what
> should "virsh domdisplay" return.
>
> The feature set should cover the needs to replace Spice as local client of 
> choice,
> including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and 
> arbitrary
> chardev/channels (for serial etc).
>
> The test Gtk4 client is also in progress, currently in development at
> https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such as
> zbus, require an upcoming release. virt-viewer & boxes will need a port to 
> Gtk4
> to make use of the shared widget.
>
> Comments welcome, as we can still adjust the QEMU side etc.

No comments?
thanks

>
> thanks
>
> Marc-André Lureau (9):
>   qemu: start the D-Bus daemon as needed
>   qemu: add chardev-vdagent capability check
>   qemu: add -display dbus capability check (to update to 6.3)
>   qemu: add -display dbus support
>   qemu: add audio type 'dbus'
>   qemu: add dbus clipboard sharing
>   qemu: add -chardev dbus
>   qemu: add usbredir type 'dbus'
>   docs: document  type dbus
>
>  docs/formatdomain.rst |  24 
>  docs/schemas/basictypes.rng   |   7 ++
>  docs/schemas/domaincommon.rng |  71 +++
>  src/bhyve/bhyve_command.c |   1 +
>  src/conf/domain_conf.c| 116 +-
>  src/conf/domain_conf.h|  14 +++
>  src/conf/domain_validate.c|  32 +++--
>  src/libxl/libxl_conf.c|   1 +
>  src/qemu/qemu_capabilities.c  |   6 +
>  src/qemu/qemu_capabilities.h  |   2 +
>  src/qemu/qemu_command.c   |  94 +-
>  src/qemu/qemu_domain.c|   1 +
>  src/qemu/qemu_domain.h|   1 +
>  src/qemu/qemu_driver.c|  10 +-
>  src/qemu/qemu_hotplug.c   |   1 +
>  src/qemu/qemu_monitor_json.c  |   1 +
>  src/qemu/qemu_process.c   |  15 ++-
>  src/qemu/qemu_validate.c  |  33 +
>  src/security/security_dac.c   |   2 +
>  src/vmx/vmx.c |   1 +
>  .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  |   1 +
>  .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  |   1 +
>  tests/domaincapsdata/qemu_6.2.0.x86_64.xml|   1 +
>  .../caps_6.1.0.x86_64.xml |   1 +
>  .../caps_6.2.0.aarch64.xml|   1 +
>  .../caps_6.2.0.x86_64.replies |  10 +-
>  .../caps_6.2.0.x86_64.xml |   2 +
>  .../graphics-dbus-address.args|  31 +
>  .../graphics-dbus-address.xml |  34 +
>  .../qemuxml2argvdata/graphics-dbus-audio.args |  32 +
>  .../qemuxml2argvdata/graphics-dbus-audio.xml  |  40 ++
>  .../graphics-dbus-chardev.args|  33 +
>  .../graphics-dbus-chardev.xml |  38 ++
>  .../graphics-dbus-clipboard.args  |  32 +
>  .../graphics-dbus-clipboard.xml   |  36 ++
>  tests/qemuxml2argvdata/graphics-dbus-p2p.args |  31 +
>  tests/qemuxml2argvdata/graphics-dbus-p2p.xml  |  36 ++
>  .../graphics-dbus-usbredir.args   |  35 ++
>  .../graphics-dbus-usbredir.xml|  36 ++
>  tests/qemuxml2argvdata/graphics-dbus.args |  31 +
>  tests/qemuxml2argvdata/graphics-dbus.xml  |  34 +
>  tests/qemuxml2argvtest.c  |  21 
>  .../graphics-dbus-address.xml |  39 ++
>  .../graphics-dbus-audio.xml   |  43 +++
>  .../qemuxml2xmloutdata/graphics-dbus-p2p.xml  |  39 ++
>  tests/qemuxml2xmloutdata/graphics-dbus.xml|  39 ++
>  tests/qemuxml2xmltest.c   |  14 +++
>  47 files changed, 1106 insertions(+), 18 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.args
>  create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.xml
>  create mode 100644 tests/qemuxml2argvdata/graphics-

Re: [PATCH] qemu: tpm: Initialize variable with NULL

[Marc-André Lureau]

On Mon, Nov 8, 2021 at 5:53 PM Stefan Berger  wrote:
>
> Initialize an autofree'd variable with NULL that causes crashes
> if a TPM 1.2 is used and the variable doesn't get a value assigned.
>
> Signed-off-by: Stefan Berger 

certainly, I wished there would be a gcc error there..

Reviewed-by: Marc-André Lureau 

> ---
>  src/qemu/qemu_tpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index b305313ad2..1992b596cb 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -610,7 +610,7 @@ qemuTPMEmulatorReconfigure(const char *storagepath,
>  {
>  g_autoptr(virCommand) cmd = NULL;
>  int exitstatus;
> -g_autofree char *activePcrBanksStr;
> +g_autofree char *activePcrBanksStr = NULL;
>  g_autofree char *swtpm_setup = virTPMGetSwtpmSetup();
>  VIR_AUTOCLOSE pwdfile_fd = -1;
>
> --
> 2.31.1
>

Re: [PATCH v2 2/2] qemu: tpm: Extend TPM domain XML with PCR banks to activate

[Marc-André Lureau]

Hi

On Mon, Nov 1, 2021 at 9:23 PM Stefan Berger  wrote:
>
> Extend the TPM domain XML with an attribute active_pcr_banks that allows
> a user to specify the PCR banks to activate before starting a VM. A comma-
> separated list of PCR banks with the choices of sha1, sha256, sha384 and
> sha512 is allowed. When the XML attribute is provided, the set of active
> PCR banks is 'enforced' by running swtpm_setup before every start of the
> VM. The activation requires that swtpm_setup v0.7 or later is installed
> and may not have any effect otherwise.
>

Is this a configuration switch that the guest is expected to handle in general?

On real hw (or ftpm), is there some bios option or equivalent to
configure the pcr banks?

If not, shouldn't this be a first-time only configuration? (and
attempts to change the value further be rejected by libvirt)

> 
>   
> 
>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2016599
>
> Signed-off-by: Stefan Berger 
> ---
>  docs/formatdomain.rst | 12 ++-
>  docs/schemas/basictypes.rng   |  6 ++
>  docs/schemas/domaincommon.rng |  5 ++
>  src/conf/domain_conf.c| 21 -
>  src/conf/domain_conf.h|  1 +
>  src/qemu/qemu_tpm.c   | 80 +++
>  src/util/virtpm.c |  1 +
>  src/util/virtpm.h |  1 +
>  tests/qemuxml2argvdata/tpm-emulator-tpm2.xml  |  2 +-
>  .../tpm-emulator-tpm2.x86_64-latest.xml   |  2 +-
>  10 files changed, 127 insertions(+), 4 deletions(-)
>
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index 0651975c88..8785a7a682 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -7537,7 +7537,7 @@ Example: usage of the TPM Emulator
>   ...
>   
> 
> - 
> + 
> 
>   
> 
> @@ -7598,6 +7598,16 @@ Example: usage of the TPM Emulator
> This attribute only works with the ``emulator`` backend. The accepted 
> values
> are ``yes`` and ``no``. :since:`Since 7.0.0`
>
> +``active_pcr_banks``
> +   The ``active_pcr_banks`` attribute indicates the names of the PCR banks
> +   of a TPM 2.0 to activate. A comma separated list of PCR banks' names
> +   must be provided. Valid names are for example sha1, sha256, sha384, and
> +   sha512. If this attribute is provided, the set of PCR banks are activated
> +   before every start of a VM and this step is logged in the swtpm's log.
> +   This attribute requires that swtpm_setup v0.7 or later is installed
> +   and may not have any effect otherwise. This attribute only works with the
> +   ``emulator`` backend. since:`Since 7.10.0`
> +
>  ``encryption``
> The ``encryption`` element allows the state of a TPM emulator to be
> encrypted. The ``secret`` must reference a secret object that holds the
> diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng
> index a221ff6295..3bd1eebdc4 100644
> --- a/docs/schemas/basictypes.rng
> +++ b/docs/schemas/basictypes.rng
> @@ -88,6 +88,12 @@
>  
>
>
> +  
> +
> +   name="pattern">(sha1|sha256|sha384|sha512){1}(,(sha1|sha256|sha384|sha512)){0,3}
> +
> +  
> +
>
>  
>10
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 67df13d90d..6801673cf1 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -5331,6 +5331,11 @@
>
> 
>
> +  
> +
> +  
> +
> +  
>  
>
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 4644d18120..bc8237fd0b 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -3207,6 +3207,7 @@ void virDomainTPMDefFree(virDomainTPMDef *def)
>  break;
>  case VIR_DOMAIN_TPM_TYPE_EMULATOR:
>  virDomainChrSourceDefClear(>data.emulator.source);
> +g_free(def->data.emulator.activePcrBanks);
>  g_free(def->data.emulator.storagepath);
>  g_free(def->data.emulator.logfile);
>  break;
> @@ -11733,7 +11734,7 @@ virDomainSmartcardDefParseXML(virDomainXMLOption 
> *xmlopt,
>   * Emulator state encryption is supported with the following:
>   *
>   * 
> - *   
> + *   
>   * 
>   *   
>   * 
> @@ -11759,6 +11760,7 @@ virDomainTPMDefParseXML(virDomainXMLOption *xmlopt,
>  g_autofree char *version = NULL;
>  g_autofree char *secretuuid = NULL;
>  g_autofree char *persistent_state = NULL;
> +g_autofree char *activePcrBanks = NULL;
>  g_autofree xmlNodePtr *backends = NULL;
>
>  def = g_new0(virDomainTPMDef, 1);
> @@ -11841,6 +11843,18 @@ virDomainTPMDefParseXML(virDomainXMLOption *xmlopt,
>  goto error;
>  }
>  }
> +if (def->version == VIR_DOMAIN_TPM_VERSION_2_0) {
> +activePcrBanks = 

Re: [PATCH v2 1/2] qemu: Move code to add encryption options for swtpm_setup into function

[Marc-André Lureau]

On Mon, Nov 1, 2021 at 9:23 PM Stefan Berger  wrote:
>
> Move the code that adds encryption options for the swtpm_setup command
> line into its own function.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 

> ---
>  src/qemu/qemu_tpm.c | 55 +++--
>  1 file changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 5a05273100..93cb04f49d 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -422,6 +422,42 @@ qemuTPMCreateConfigFiles(const char *swtpm_setup)
>  }
>
>
> +/*
> + * Add encryption parameters to swtpm_setup command line.
> + *
> + * @cmd: virCommand to add options to
> + * @swtpm_setup: swtpm_setup tool path
> + * @secretuuid: The secret's uuid; may be NULL
> + */
> +static int
> +qemuTPMVirCommandAddEncryption(virCommand *cmd,
> +   const char *swtpm_setup,
> +   const unsigned char *secretuuid)
> +{
> +int pwdfile_fd;
> +
> +if (!secretuuid)
> +return 0;
> +
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD)) {
> +virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED,
> +_("%s does not support passing a passphrase using a file "
> +  "descriptor"), swtpm_setup);
> +return -1;
> +}
> +if ((pwdfile_fd = qemuTPMSetupEncryption(secretuuid, cmd)) < 0)
> +return -1;
> +
> +virCommandAddArg(cmd, "--pwdfile-fd");
> +virCommandAddArgFormat(cmd, "%d", pwdfile_fd);
> +virCommandAddArgList(cmd, "--cipher", "aes-256-cbc", NULL);
> +virCommandPassFD(cmd, pwdfile_fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT);
> +
> +return 0;
> +}
> +
> +
>  /*
>   * qemuTPMEmulatorRunSetup
>   *
> @@ -495,23 +531,8 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  break;
>  }
>
> -if (secretuuid) {
> -if (!virTPMSwtpmSetupCapsGet(
> -VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD)) {
> -virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED,
> -_("%s does not support passing a passphrase using a file "
> -  "descriptor"), swtpm_setup);
> -return -1;
> -}
> -if ((pwdfile_fd = qemuTPMSetupEncryption(secretuuid, cmd)) < 0)
> -return -1;
> -
> -virCommandAddArg(cmd, "--pwdfile-fd");
> -virCommandAddArgFormat(cmd, "%d", pwdfile_fd);
> -virCommandAddArgList(cmd, "--cipher", "aes-256-cbc", NULL);
> -virCommandPassFD(cmd, pwdfile_fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT);
> -pwdfile_fd = -1;
> -}
> +if (qemuTPMVirCommandAddEncryption(cmd, swtpm_setup, secretuuid) < 0)
> +return -1;
>
>  if (!incomingMigration) {
>  virCommandAddArgList(cmd,
> --
> 2.31.1
>

Re: [PATCH] qemu: Extend qemu.conf with PCR banks to activate during 'TPM manufacturing'

[Marc-André Lureau]

Hi

On Wed, Oct 27, 2021 at 9:00 PM Stefan Berger  wrote:
>
> Extend qemu.conf with a configration option swtpm_active_pcr_banks that
> allows a user to set a comma-separated list of PCR banks to activate
> during 'TPM manufacturing'. Valid PCR banks are sha1,sha256,sha384 and
> sha512.
>

Why not put this option in swtpm_setup.conf instead?

> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2016599
>
> Signed-off-by: Stefan Berger 
> ---
>  src/qemu/qemu.conf   | 8 
>  src/qemu/qemu_conf.c | 6 ++
>  src/qemu/qemu_conf.h | 1 +
>  src/qemu/qemu_tpm.c  | 8 
>  4 files changed, 23 insertions(+)
>
> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> index 71fd125699..7aa151ed55 100644
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -915,6 +915,14 @@
>  #swtpm_user = "tss"
>  #swtpm_group = "tss"
>
> +# The PCR banks to activate during 'TPM manufacturing' before a swtpm 
> instance
> +# is started the first time.
> +#
> +# A comma-separated list without spaces containing sha1,sha256,sha384, or
> +# sha512. The default is 'sha256'.
> +#
> +# swtpm_active_pcr_banks = "sha256,sha384"
> +
>  # For debugging and testing purposes it's sometimes useful to be able to 
> disable
>  # libvirt behaviour based on the capabilities of the qemu process. This 
> option
>  # allows to do so. DO _NOT_ use in production and beaware that the behaviour
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 0451bc70ac..a62525385e 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -384,6 +384,8 @@ static void virQEMUDriverConfigDispose(void *obj)
>  g_strfreev(cfg->capabilityfilters);
>
>  g_free(cfg->deprecationBehavior);
> +
> +g_free(cfg->swtpmActivePcrBanks);
>  }
>
>
> @@ -1030,6 +1032,10 @@ virQEMUDriverConfigLoadSWTPMEntry(virQEMUDriverConfig 
> *cfg,
>  if (swtpm_group && virGetGroupID(swtpm_group, >swtpm_group) < 0)
>  return -1;
>
> +if (virConfGetValueString(conf, "swtpm_active_pcr_banks",
> +  >swtpmActivePcrBanks) < 0)
> +return -1;
> +
>  return 0;
>  }
>
> diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
> index 2f64e39a18..37461d9e31 100644
> --- a/src/qemu/qemu_conf.h
> +++ b/src/qemu/qemu_conf.h
> @@ -219,6 +219,7 @@ struct _virQEMUDriverConfig {
>
>  uid_t swtpm_user;
>  gid_t swtpm_group;
> +char *swtpmActivePcrBanks;
>
>  char **capabilityfilters;
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index e1b08a66c5..69fd1e67e3 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -448,6 +448,7 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  bool privileged,
>  uid_t swtpm_user,
>  gid_t swtpm_group,
> +const char *swtpmActivePcrBanks,
>  const char *logfile,
>  const virDomainTPMVersion tpmversion,
>  const unsigned char *secretuuid,
> @@ -512,6 +513,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  }
>
>  if (!incomingMigration) {
> +if (!swtpmActivePcrBanks)
> +swtpmActivePcrBanks = "sha256";
> +
>  virCommandAddArgList(cmd,
>   "--tpm-state", storagepath,
>   "--vmid", vmid,
> @@ -521,6 +525,7 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "--create-platform-cert",
>   "--lock-nvram",
>   "--not-overwrite",
> + "--pcr-banks", swtpmActivePcrBanks,
>   NULL);
>  } else {
>  virCommandAddArgList(cmd,
> @@ -568,6 +573,7 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm,
>  bool privileged,
>  uid_t swtpm_user,
>  gid_t swtpm_group,
> +const char *swtpmActivePcrBanks,
>  const char *swtpmStateDir,
>  const char *shortName,
>  bool incomingMigration)
> @@ -593,6 +599,7 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm,
>  if (created &&
>  qemuTPMEmulatorRunSetup(tpm->data.emulator.storagepath, vmname, 
> vmuuid,
>  privileged, swtpm_user, swtpm_group,
> +swtpmActivePcrBanks,
>  tpm->data.emulator.logfile, tpm->version,
>  secretuuid, incomingMigration) < 0)
>  goto error;
> @@ -812,6 +819,7 @@ qemuExtTPMStartEmulator(virQEMUDriver *driver,
>  driver->privileged,
>  cfg->swtpm_user,
>  cfg->swtpm_group,
> +

Re: [PATCH v5] qemu: tpm: Run swtpm_setup --create-config-files in session mode

[Marc-André Lureau]

On Tue, Oct 19, 2021 at 5:43 PM Stefan Berger  wrote:

> Using swtpm v0.7.0 we can run swtpm_setup to create default config files
> for swtpm_setup and swtpm-localca in session mode. Now a user can start
> a VM with an attached TPM without having to run this program on the
> command line before. This program needs to run once.
>
> This patch addresses the issue raised in
> https://bugzilla.redhat.com/show_bug.cgi?id=2010649
>
> Signed-off-by: Stefan Berger 
>

Reviewed-by: Marc-André Lureau 


> ---
> v5:
>   - Address Daniel's comments on v4
>   - Pass swtpm_setup to function since it's already been looked up
>
> v4:
>   - Append stderr output to virReportError if swtpm_setup fails
>
> v3:
>   - Removed logfile parameter
>
> v2:
>   - fixed return code if swtpm_setup doesn't support the option
> ---
>  src/qemu/qemu_tpm.c | 40 
>  src/util/virtpm.c   |  1 +
>  src/util/virtpm.h   |  1 +
>  3 files changed, 42 insertions(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 100481503c..e1b08a66c5 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -385,6 +385,43 @@ qemuTPMSetupEncryption(const unsigned char
> *secretuuid,
>  return virCommandSetSendBuffer(cmd, g_steal_pointer(),
> secret_len);
>  }
>
> +
> +/*
> + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files
> skip-if-exist
> + */
> +static int
> +qemuTPMCreateConfigFiles(const char *swtpm_setup)
> +{
> +g_autoptr(virCommand) cmd = NULL;
> +g_autofree char *errbuf = NULL;
> +int exitstatus;
> +
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES))
> +return 0;
> +
> +cmd = virCommandNew(swtpm_setup);
> +if (!cmd)
> +return -1;
> +
> +virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist",
> NULL);
> +virCommandClearCaps(cmd);
> +virCommandSetErrorBuffer(cmd, );
> +
> +if (virCommandRun(cmd, ) < 0)
> +return -1;
> +if (exitstatus != 0) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Could not run '%s' to create config files. "
> + "exitstatus: %d;\nError: %s"),
> +  swtpm_setup, exitstatus, errbuf);
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +
>  /*
>   * qemuTPMEmulatorRunSetup
>   *
> @@ -432,6 +469,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "this requires privileged mode for a "
>   "TPM 1.2\n"), 0600);
>
> +if (!privileged && qemuTPMCreateConfigFiles(swtpm_setup) < 0)
> +return -1;
> +
>  cmd = virCommandNew(swtpm_setup);
>  if (!cmd)
>  return -1;
> diff --git a/src/util/virtpm.c b/src/util/virtpm.c
> index 1a567139b4..0f50de866c 100644
> --- a/src/util/virtpm.c
> +++ b/src/util/virtpm.c
> @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature,
>  VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
>VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
>"cmdarg-pwdfile-fd",
> +  "cmdarg-create-config-files",
>  );
>
>  /**
> diff --git a/src/util/virtpm.h b/src/util/virtpm.h
> index d021a083b4..3bb03b3b33 100644
> --- a/src/util/virtpm.h
> +++ b/src/util/virtpm.h
> @@ -38,6 +38,7 @@ typedef enum {
>
>  typedef enum {
>  VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES,
>
>  VIR_TPM_SWTPM_SETUP_FEATURE_LAST
>  } virTPMSwtpmSetupFeature;
> --
> 2.31.1
>
>

Re: [PATCH v4] qemu: tpm: Run swtpm_setup --create-config-files in session mode

[Marc-André Lureau]

Hi

On Wed, Oct 13, 2021 at 4:57 PM Stefan Berger  wrote:

> Using swtpm v0.7.0 we can run swtpm_setup to create default config files
> for swtpm_setup and swtpm-localca in session mode. Now a user can start
> a VM with an attached TPM without having to run this program on the
> command line before. This program needs to run once.
>
> This patch addresses the issue raised in
> https://bugzilla.redhat.com/show_bug.cgi?id=2010649
>
> Signed-off-by: Stefan Berger 
>
> ---
> v4:
>   - Append stderr output to virReportError if swtpm_setup fails
>
> v3:
>   - Removed logfile parameter
>
> v2:
>   - fixed return code if swtpm_setup doesn't support the option
> ---
>  src/qemu/qemu_tpm.c | 42 ++
>  src/util/virtpm.c   |  1 +
>  src/util/virtpm.h   |  1 +
>  3 files changed, 44 insertions(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 100481503c..f797a87fdc 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -385,6 +385,45 @@ qemuTPMSetupEncryption(const unsigned char
> *secretuuid,
>  return virCommandSetSendBuffer(cmd, g_steal_pointer(),
> secret_len);
>  }
>
> +
> +/*
> + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files
> skip-if-exist
> + */
> +static int
> +qemuTPMCreateConfigFiles(void)
> +{
> +g_autofree char *swtpm_setup = virTPMGetSwtpmSetup();
> +g_autoptr(virCommand) cmd = NULL;
> +g_autofree char *errbuf = NULL;
> +int exitstatus;
> +
> +if (!swtpm_setup)
> +return -1;
> +
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES))
> +return 0;
> +
> +cmd = virCommandNew(swtpm_setup);
> +if (!cmd)
> +return -1;
> +
> +virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist",
> NULL);
> +virCommandClearCaps(cmd);
> +virCommandSetErrorBuffer(cmd, );
> +
> +if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Could not run '%s' to create config files. "
> + "exitstatus: %d;\nError: %s"),
> +  swtpm_setup, exitstatus, errbuf);
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +
>  /*
>   * qemuTPMEmulatorRunSetup
>   *
> @@ -432,6 +471,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "this requires privileged mode for a "
>   "TPM 1.2\n"), 0600);
>
> +if (!privileged && qemuTPMCreateConfigFiles())
> +return -1;
> +
>  cmd = virCommandNew(swtpm_setup);
>  if (!cmd)
>  return -1;
> diff --git a/src/util/virtpm.c b/src/util/virtpm.c
> index 1a567139b4..0f50de866c 100644
> --- a/src/util/virtpm.c
> +++ b/src/util/virtpm.c
> @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature,
>  VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
>VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
>"cmdarg-pwdfile-fd",
> +  "cmdarg-create-config-files",
>  );
>
>  /**
> diff --git a/src/util/virtpm.h b/src/util/virtpm.h
> index d021a083b4..3bb03b3b33 100644
> --- a/src/util/virtpm.h
> +++ b/src/util/virtpm.h
> @@ -38,6 +38,7 @@ typedef enum {
>
>  typedef enum {
>  VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES,
>
>  VIR_TPM_SWTPM_SETUP_FEATURE_LAST
>  } virTPMSwtpmSetupFeature;
> --
> 2.31.1
>
>
lgtm,
Reviewed-by: Marc-André Lureau 

Re: [PATCH v3] qemu: tpm: Run swtpm_setup --create-config-files in session mode

[Marc-André Lureau]

Hi

On Fri, Oct 8, 2021 at 10:31 PM Stefan Berger  wrote:

>
> On 10/8/21 12:33 PM, Marc-André Lureau wrote:
>
> Hi
>
> On Fri, Oct 8, 2021 at 6:44 PM Stefan Berger 
> wrote:
>
>> Using swtpm v0.7.0 we can run swtpm_setup to create default config files
>> for swtpm_setup and swtpm-localca in session mode. Now a user can start
>> a VM with an attached TPM without having to run this program on the
>> command line before. This program needs to run once.
>>
>> This patch addresses the issue raised in
>> https://bugzilla.redhat.com/show_bug.cgi?id=2010649
>>
>> Signed-off-by: Stefan Berger 
>>
>> ---
>> v3:
>>   - Removed logfile parameter
>>
>
> I guess it's redirected to libvirt log then?
>
> So you are saying it should capture the stderr output ?
>

Something should, not sure what's the best practice today with libvirt.
Someone more familiar should say.


>
>> v2:
>>   - fixed return code if swtpm_setup doesn't support the option
>> ---
>>  src/qemu/qemu_tpm.c | 39 +++
>>  src/util/virtpm.c   |  1 +
>>  src/util/virtpm.h   |  1 +
>>  3 files changed, 41 insertions(+)
>>
>> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
>> index 100481503c..434c357c24 100644
>> --- a/src/qemu/qemu_tpm.c
>> +++ b/src/qemu/qemu_tpm.c
>> @@ -385,6 +385,42 @@ qemuTPMSetupEncryption(const unsigned char
>> *secretuuid,
>>  return virCommandSetSendBuffer(cmd, g_steal_pointer(),
>> secret_len);
>>  }
>>
>> +
>> +/*
>> + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files
>> skip-if-exist
>> + */
>> +static int
>> +qemuTPMCreateConfigFiles(void)
>> +{
>> +g_autofree char *swtpm_setup = virTPMGetSwtpmSetup();
>> +g_autoptr(virCommand) cmd = NULL;
>> +int exitstatus;
>> +
>> +if (!swtpm_setup)
>> +return -1;
>>
>
> I think what Daniel was saying is that this shouldn't fail suddenly for
> users with older swtpm that already have the configuration setup.
>
>
> The above only fails if swtm_setup is not installed, if that's what you
> mean. That's when swtpm_setup is NULL.
>
> If you run `swptm_setup --create-config-files skip-if-exist` when any one
> of the 3 config files already exist, it will do nothing and exit with 0.
>
>
>
Oh I see, I misread, looks correct then


> +
>> +if (!virTPMSwtpmSetupCapsGet(
>> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES))
>> +return 0;
>>
>
> This is the case when swtpm_setup doesn't support --create-config-files.
> That's when the user has to use the old
> /usr/share/swtpm/swptm-create-user-config-files to create the config files,
> which will then be located at the same place that `swptm_setup
> --create-config-files skip-if-exist` would create them or check whether any
> one of them exist and skip.
>
> 3 config files will be created and if the user then removes 1 or 2 of them
> he created an invalid configuration and the start of the next VM will fail
> due to a bad configuration with missing config files. The config files
> would only be created again if all 3 were missing.
>
>
> +
>> +cmd = virCommandNew(swtpm_setup);
>> +if (!cmd)
>> +return -1;
>> +
>> +virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist",
>> NULL);
>> +virCommandClearCaps(cmd);
>> +
>> +if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
>> +virReportError(VIR_ERR_INTERNAL_ERROR,
>> +   _("Could not run '%s' to create config files.
>> exitstatus: %d",
>> +  swtpm_setup, exitstatus);
>> +return -1;
>>
> In the error case the stderr output of swtpm_setup should probably show up
> here?
>
>
> +}
>> +
>> +return 0;
>> +}
>> +
>> +
>>  /*
>>   * qemuTPMEmulatorRunSetup
>>   *
>> @@ -432,6 +468,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>>   "this requires privileged mode for a "
>>   "TPM 1.2\n"), 0600);
>>
>> +if (!privileged && qemuTPMCreateConfigFiles())
>> +return -1;
>> +
>>  cmd = virCommandNew(swtpm_setup);
>>  if (!cmd)
>>  return -1;
>> diff --git a/src/util/virtpm.c b/src/util/virtpm.c
>> index 1a567139b4..0f50de866c 100644
>> --- a/src/util/virtpm.c
>> +++ b/src/util/virtpm.c
>> @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature,
>>  VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
>>VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
>>"cmdarg-pwdfile-fd",
>> +  "cmdarg-create-config-files",
>>  );
>>
>>  /**
>> diff --git a/src/util/virtpm.h b/src/util/virtpm.h
>> index d021a083b4..3bb03b3b33 100644
>> --- a/src/util/virtpm.h
>> +++ b/src/util/virtpm.h
>> @@ -38,6 +38,7 @@ typedef enum {
>>
>>  typedef enum {
>>  VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
>> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES,
>>
>>  VIR_TPM_SWTPM_SETUP_FEATURE_LAST
>>  } virTPMSwtpmSetupFeature;
>> --
>> 2.31.1
>>
>>

Re: [PATCH v3] qemu: tpm: Run swtpm_setup --create-config-files in session mode

[Marc-André Lureau]

Hi

On Fri, Oct 8, 2021 at 6:44 PM Stefan Berger  wrote:

> Using swtpm v0.7.0 we can run swtpm_setup to create default config files
> for swtpm_setup and swtpm-localca in session mode. Now a user can start
> a VM with an attached TPM without having to run this program on the
> command line before. This program needs to run once.
>
> This patch addresses the issue raised in
> https://bugzilla.redhat.com/show_bug.cgi?id=2010649
>
> Signed-off-by: Stefan Berger 
>
> ---
> v3:
>   - Removed logfile parameter
>

I guess it's redirected to libvirt log then?


> v2:
>   - fixed return code if swtpm_setup doesn't support the option
> ---
>  src/qemu/qemu_tpm.c | 39 +++
>  src/util/virtpm.c   |  1 +
>  src/util/virtpm.h   |  1 +
>  3 files changed, 41 insertions(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 100481503c..434c357c24 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -385,6 +385,42 @@ qemuTPMSetupEncryption(const unsigned char
> *secretuuid,
>  return virCommandSetSendBuffer(cmd, g_steal_pointer(),
> secret_len);
>  }
>
> +
> +/*
> + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files
> skip-if-exist
> + */
> +static int
> +qemuTPMCreateConfigFiles(void)
> +{
> +g_autofree char *swtpm_setup = virTPMGetSwtpmSetup();
> +g_autoptr(virCommand) cmd = NULL;
> +int exitstatus;
> +
> +if (!swtpm_setup)
> +return -1;
>

I think what Daniel was saying is that this shouldn't fail suddenly for
users with older swtpm that already have the configuration setup.

+
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES))
> +return 0;
> +
> +cmd = virCommandNew(swtpm_setup);
> +if (!cmd)
> +return -1;
> +
> +virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist",
> NULL);
> +virCommandClearCaps(cmd);
> +
> +if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Could not run '%s' to create config files.
> exitstatus: %d",
> +  swtpm_setup, exitstatus);
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +
>  /*
>   * qemuTPMEmulatorRunSetup
>   *
> @@ -432,6 +468,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "this requires privileged mode for a "
>   "TPM 1.2\n"), 0600);
>
> +if (!privileged && qemuTPMCreateConfigFiles())
> +return -1;
> +
>  cmd = virCommandNew(swtpm_setup);
>  if (!cmd)
>  return -1;
> diff --git a/src/util/virtpm.c b/src/util/virtpm.c
> index 1a567139b4..0f50de866c 100644
> --- a/src/util/virtpm.c
> +++ b/src/util/virtpm.c
> @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature,
>  VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
>VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
>"cmdarg-pwdfile-fd",
> +  "cmdarg-create-config-files",
>  );
>
>  /**
> diff --git a/src/util/virtpm.h b/src/util/virtpm.h
> index d021a083b4..3bb03b3b33 100644
> --- a/src/util/virtpm.h
> +++ b/src/util/virtpm.h
> @@ -38,6 +38,7 @@ typedef enum {
>
>  typedef enum {
>  VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES,
>
>  VIR_TPM_SWTPM_SETUP_FEATURE_LAST
>  } virTPMSwtpmSetupFeature;
> --
> 2.31.1
>
>

Re: [PATCH v2] qemu: tpm: Run swtpm_setup --create-config-files in session mode

[Marc-André Lureau]

On Fri, Oct 8, 2021 at 5:56 PM Stefan Berger  wrote:

> Using swtpm v0.7.0 we can run swtpm_setup to create default config files
> for swtpm_setup and swtpm-localca in session mode. Now a user can start
> a VM with an attached TPM without having to run this program on the
> command line before. This program needs to run once.
>
> This patch addresses the issue raised in
> https://bugzilla.redhat.com/show_bug.cgi?id=2010649
>
> Signed-off-by: Stefan Berger 
>

> v2:
>   - fixed return code if swtpm_setup doesn't support the option
> ---
>  src/qemu/qemu_tpm.c | 43 +++
>  src/util/virtpm.c   |  1 +
>  src/util/virtpm.h   |  1 +
>  3 files changed, 45 insertions(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 100481503c..bf6c8e5ad5 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -385,6 +385,46 @@ qemuTPMSetupEncryption(const unsigned char
> *secretuuid,
>  return virCommandSetSendBuffer(cmd, g_steal_pointer(),
> secret_len);
>  }
>
> +
> +/*
> + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files
> skip-if-exist
> + *
> + * @logfile: The file to write the log into; it must be writable
> + *   for the user given by userid or 'tss'
> + */
> +static int
> +qemuTPMCreateConfigFiles(const char *logfile)
> +{
> +g_autofree char *swtpm_setup = virTPMGetSwtpmSetup();
> +g_autoptr(virCommand) cmd = NULL;
> +int exitstatus;
> +
> +if (!swtpm_setup)
> +return -1;
> +
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES))
> +return 0;
> +
> +cmd = virCommandNew(swtpm_setup);
> +if (!cmd)
> +return -1;
> +
> +virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist",
> NULL);
> +virCommandClearCaps(cmd);
> +
> +if (virCommandRun(cmd, ) < 0 || exitstatus != 0) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Could not run '%s' to create config files.
> exitstatus: %d; "
> + "Check error log '%s' for details."),
> +  swtpm_setup, exitstatus, logfile);
>

logfile isn't used, it seems

+return -1;
> +}
> +
> +return 0;
> +}
> +
> +
>  /*
>   * qemuTPMEmulatorRunSetup
>   *
> @@ -432,6 +472,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "this requires privileged mode for a "
>   "TPM 1.2\n"), 0600);
>
> +if (!privileged && qemuTPMCreateConfigFiles(logfile))
> +return -1;
> +
>  cmd = virCommandNew(swtpm_setup);
>  if (!cmd)
>  return -1;
> diff --git a/src/util/virtpm.c b/src/util/virtpm.c
> index 1a567139b4..0f50de866c 100644
> --- a/src/util/virtpm.c
> +++ b/src/util/virtpm.c
> @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature,
>  VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
>VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
>"cmdarg-pwdfile-fd",
> +  "cmdarg-create-config-files",
>  );
>
>  /**
> diff --git a/src/util/virtpm.h b/src/util/virtpm.h
> index d021a083b4..3bb03b3b33 100644
> --- a/src/util/virtpm.h
> +++ b/src/util/virtpm.h
> @@ -38,6 +38,7 @@ typedef enum {
>
>  typedef enum {
>  VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES,
>
>  VIR_TPM_SWTPM_SETUP_FEATURE_LAST
>  } virTPMSwtpmSetupFeature;
> --
> 2.31.1
>
>
lgtm otherwise

Re: [PATCH 08/14] chardev: reject use of 'wait' flag for socket client chardevs

[Marc-André Lureau]

On Wed, Feb 24, 2021 at 5:15 PM Daniel P. Berrangé 
wrote:

> This only makes sense conceptually when used with listener chardevs.
>
> Signed-off-by: Daniel P. Berrangé 
>

Reviewed-by: Marc-André Lureau 

---
>  chardev/char-socket.c| 12 
>  docs/system/deprecated.rst   |  6 --
>  docs/system/removed-features.rst |  6 ++
>  3 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
> index 9061981f6d..b24618b581 100644
> --- a/chardev/char-socket.c
> +++ b/chardev/char-socket.c
> @@ -1336,14 +1336,10 @@ static bool
> qmp_chardev_validate_socket(ChardevSocket *sock,
>  return false;
>  }
>  if (sock->has_wait) {
> -warn_report("'wait' option is deprecated with "
> -"socket in client connect mode");
> -if (sock->wait) {
> -error_setg(errp, "%s",
> -   "'wait' option is incompatible with "
> -   "socket in client connect mode");
> -return false;
> -}
> +error_setg(errp, "%s",
> +   "'wait' option is incompatible with "
> +   "socket in client connect mode");
> +return false;
>  }
>  }
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 78474f0845..c69887dca8 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -192,12 +192,6 @@ Since the ``dirty-bitmaps`` field is optionally
> present in both the old and
>  new locations, clients must use introspection to learn where to anticipate
>  the field if/when it does appear in command output.
>
> -chardev client socket with ``wait`` option (since 4.0)
> -''
> -
> -Character devices creating sockets in client mode should not specify
> -the 'wait' field, which is only applicable to sockets in server mode
> -
>  ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
>  
>
> diff --git a/docs/system/removed-features.rst
> b/docs/system/removed-features.rst
> index 7942c2e513..870a222062 100644
> --- a/docs/system/removed-features.rst
> +++ b/docs/system/removed-features.rst
> @@ -106,6 +106,12 @@ The ``query-cpus`` command is replaced by the
> ``query-cpus-fast`` command.
>  The ``arch`` output member of the ``query-cpus-fast`` command is
>  replaced by the ``target`` output member.
>
> +chardev client socket with ``wait`` option (removed in 6.0)
> +'''
> +
> +Character devices creating sockets in client mode should not specify
> +the 'wait' field, which is only applicable to sockets in server mode
> +
>  Human Monitor Protocol (HMP) commands
>  -
>
> --
> 2.29.2
>
>

Re: [PATCH v2] src: use singular form instead of plural, for guest disk info

[Marc-André Lureau]

On Wed, Dec 2, 2020 at 4:47 PM Daniel P. Berrangé 
wrote:

> Existing practice with the filesystem fields reported for the
> virDomainGetGuestInfo API is to use the singular form for
> field names. Ensure the disk info follows this practice.
>
> Fixes
>
>   commit 05a75ca2ce743bc0bb119fb8d532ff84646fafa3
>   Author: Marc-André Lureau 
>   Date:   Fri Nov 20 22:09:46 2020 +0400
>
> domain: add disk informations to virDomainGetGuestInfo
>
>   commit 0cb2d9f05d00497a715352f6ea28cf8fb6921731
>   Author: Marc-André Lureau 
>   Date:   Fri Nov 20 22:09:47 2020 +0400
>
> qemu_driver: report guest disk informations
>
>   commit 172b8304352b1945e328394e61290a24446280dd
>   Author: Marc-André Lureau 
>   Date:   Fri Nov 20 22:09:48 2020 +0400
>
> virsh: add --disk informations to guestinfo command
>
> Signed-off-by: Daniel P. Berrangé 
>

Reviewed-by: Marc-André Lureau 

---
>
> In v2: also update docs and virsh
>
>  docs/manpages/virsh.rst | 20 ++--
>  src/libvirt-domain.c| 14 +++---
>  src/qemu/qemu_driver.c  | 14 +++---
>  tools/virsh-domain.c|  6 +++---
>  4 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
> index 9ef6b68422..aa54bc21ef 100644
> --- a/docs/manpages/virsh.rst
> +++ b/docs/manpages/virsh.rst
> @@ -2679,7 +2679,7 @@ guestinfo
>  ::
>
> guestinfo domain [--user] [--os] [--timezone] [--hostname]
> [--filesystem]
> -  [--disks]
> +  [--disk]
>
>  Print information about the guest from the point of view of the guest
> agent.
>  Note that this command requires a guest agent to be configured and
> running in
> @@ -2690,7 +2690,7 @@ are supported by the guest agent. You can limit the
> types of information that
>  are returned by specifying one or more flags.  If a requested information
>  type is not supported, the processes will provide an exit code of 1.
>  Available information types flags are *--user*, *--os*,
> -*--timezone*, *--hostname*, *--filesystem* and *--disks*.
> +*--timezone*, *--hostname*, *--filesystem* and *--disk*.
>
>  Note that depending on the hypervisor type and the version of the guest
> agent
>  running within the domain, not all of the following information may be
> @@ -2747,15 +2747,15 @@ returned:
>  * ``fs..disk..serial`` - the serial number of disk 
>  * ``fs..disk..device`` - the device node of disk 
>
> -*--disks* returns:
> +*--disk* returns:
>
> -* ``disks.count`` - the number of disks defined on this domain
> -* ``disks..name`` - device node (Linux) or device UNC (Windows)
> -* ``disks..partition`` - whether this is a partition or disk
> -* ``disks..dependencies.count`` - the number of device dependencies
> -* ``disks..dependencies..name`` - a dependency name
> -* ``disks..alias`` - the device alias of the disk (e.g. sda)
> -* ``disks..guest_alias`` - optional alias assigned to the disk
> +* ``disk.count`` - the number of disks defined on this domain
> +* ``disk..name`` - device node (Linux) or device UNC (Windows)
> +* ``disk..partition`` - whether this is a partition or disk
> +* ``disk..dependency.count`` - the number of device dependencies
> +* ``disk..dependency..name`` - a dependency name
> +* ``disk..alias`` - the device alias of the disk (e.g. sda)
> +* ``disk..guest_alias`` - optional alias assigned to the disk
>
>
>  guestvcpus
> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
> index 35e95e5395..f5cd43ecea 100644
> --- a/src/libvirt-domain.c
> +++ b/src/libvirt-domain.c
> @@ -12345,17 +12345,17 @@ virDomainSetVcpu(virDomainPtr domain,
>   *  Returns information about the disks within the domain.  The typed
>   *  parameter keys are in this format:
>   *
> - *  "disks.count" - the number of disks defined on this domain
> + *  "disk.count" - the number of disks defined on this domain
>   *  as an unsigned int
> - *  "disks..name" - device node (Linux) or device UNC (Windows)
> - *  "disks..partition" - whether this is a partition or disk
> - *  "disks..dependencies.count" - the number of device
> dependencies
> + *  "disk..name" - device node (Linux) or device UNC (Windows)
> + *  "disk..partition" - whether this is a partition or disk
> + *  "disk..dependency.count" - the number of device dependencies
>   *  e.g. for LVs of the LVM this will
>   *  hold the list of PVs, for LUKS encrypted volume
> this will
>   *  contain the disk where the volume is placed.
> (Linux)
> - *  "disks..dependencies..name&

Re: [libvirt PATCH 0/9] qemu: report guest disks informations

[Marc-André Lureau]

Hi

On Mon, Nov 30, 2020 at 11:16 PM Michal Privoznik  wrote:
>
> On 11/20/20 7:09 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Hi,
> >
> > The following series extends virDomainGetGuestInfo to report disk 
> > informations
> > provided by the new QGA "guest-get-disks" command in QEMU 5.2.
> >
> > Please review,
> >
> > Fixes:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1899527
> >
> > Marc-André Lureau (9):
> >qemu_agent: rename qemuAgentDiskInfo->qemuAgentDiskAddress
> >qemu_agent: export qemuAgentDiskAddressFree & add g_auto
> >qemu_agent: factor out qemuAgentGetDiskAddress
> >util: json: add virJSONValueObjectGetStringArray convenience
> >qemu: use virJSONValueObjectGetStringArray
> >qemu_agent: add qemuAgentGetDisks
> >domain: add disk informations to virDomainGetGuestInfo
> >qemu_driver: report guest disk informations
> >virsh: add --disk informations to guestinfo command
> >
> >   include/libvirt/libvirt-domain.h |   1 +
> >   src/libvirt-domain.c |  17 +++
> >   src/libvirt_private.syms |   1 +
> >   src/qemu/qemu_agent.c| 182 +++
> >   src/qemu/qemu_agent.h|  25 -
> >   src/qemu/qemu_driver.c   | 103 -
> >   src/qemu/qemu_monitor_json.c |  34 +-
> >   src/util/virjson.c   |  30 +
> >   src/util/virjson.h   |   1 +
> >   tests/qemuagenttest.c| 111 +++
> >   tools/virsh-domain.c |   6 +
> >   11 files changed, 430 insertions(+), 81 deletions(-)
> >
>
> Patches look good. A huge sorry for letting these slip the release. To
> make it up to you, I'm proposing couple of adjustments and if you agree
> I will squash in proposed diffs before pushing - so that you don't have
> to send v2.
>


Fine to me,

> Tentative:
> Reviewed-by: Michal Privoznik 
>

thanks!

Re: [libvirt PATCH 9/9] virsh: add --disk informations to guestinfo command

[Marc-André Lureau]

Hi

On Mon, Nov 30, 2020 at 11:16 PM Michal Privoznik  wrote:
>
> On 11/20/20 7:09 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   tools/virsh-domain.c | 6 ++
> >   1 file changed, 6 insertions(+)
>
> Missing manpage addition. How about:
>
> diff --git i/docs/manpages/virsh.rst w/docs/manpages/virsh.rst
> index 86deaa486d..9ef6b68422 100644
> --- i/docs/manpages/virsh.rst
> +++ w/docs/manpages/virsh.rst
> @@ -2679,6 +2679,7 @@ guestinfo
>   ::
>
>  guestinfo domain [--user] [--os] [--timezone] [--hostname]
> [--filesystem]
> +  [--disks]
>
>   Print information about the guest from the point of view of the guest
> agent.
>   Note that this command requires a guest agent to be configured and
> running in
> @@ -2689,7 +2690,7 @@ are supported by the guest agent. You can limit
> the types of information that
>   are returned by specifying one or more flags.  If a requested information
>   type is not supported, the processes will provide an exit code of 1.
>   Available information types flags are *--user*, *--os*,
> -*--timezone*, *--hostname*, and *--filesystem*.
> +*--timezone*, *--hostname*, *--filesystem* and *--disks*.
>
>   Note that depending on the hypervisor type and the version of the
> guest agent
>   running within the domain, not all of the following information may be
> @@ -2746,6 +2747,16 @@ returned:
>   * ``fs..disk..serial`` - the serial number of disk 
>   * ``fs..disk..device`` - the device node of disk 
>
> +*--disks* returns:
> +
> +* ``disks.count`` - the number of disks defined on this domain
> +* ``disks..name`` - device node (Linux) or device UNC (Windows)
> +* ``disks..partition`` - whether this is a partition or disk
> +* ``disks..dependencies.count`` - the number of device dependencies
> +* ``disks..dependencies..name`` - a dependency name
> +* ``disks..alias`` - the device alias of the disk (e.g. sda)
> +* ``disks..guest_alias`` - optional alias assigned to the disk
> +
>
>   guestvcpus
>   --

Looks good, thanks

Re: [libvirt PATCH 5/9] qemu: use virJSONValueObjectGetStringArray

[Marc-André Lureau]

On Mon, Nov 30, 2020 at 11:16 PM Michal Privoznik  wrote:
>
> On 11/20/20 7:09 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > There might be more potential users around, I haven't looked thoroughly.
>
>
> Quick git grep showed two more: qemuAgentSSHGetAuthorizedKeys() and
> qemuMonitorJSONGetStringListProperty(). But that can be done in a
> separate patch.
>
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_monitor_json.c | 34 ++
> >   1 file changed, 6 insertions(+), 28 deletions(-)
> >
> > diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
> > index 723bdb4426..3588a0c426 100644
> > --- a/src/qemu/qemu_monitor_json.c
> > +++ b/src/qemu/qemu_monitor_json.c
> > @@ -7533,10 +7533,7 @@ qemuMonitorJSONGetStringArray(qemuMonitorPtr mon, 
> > const char *qmpCmd,
> >   int ret = -1;
> >   virJSONValuePtr cmd;
> >   virJSONValuePtr reply = NULL;
> > -virJSONValuePtr data;
> > -char **list = NULL;
> > -size_t n = 0;
> > -size_t i;
> > +g_auto(GStrv) list = NULL;
> >
> >   *array = NULL;
> >
> > @@ -7554,32 +7551,13 @@ qemuMonitorJSONGetStringArray(qemuMonitorPtr mon, 
> > const char *qmpCmd,
> >   if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_ARRAY) < 0)
> >   goto cleanup;
> >
> > -data = virJSONValueObjectGetArray(reply, "return");
> > -n = virJSONValueArraySize(data);
> > -
> > -/* null-terminated list */
> > -list = g_new0(char *, n + 1);
> > -
> > -for (i = 0; i < n; i++) {
> > -virJSONValuePtr child = virJSONValueArrayGet(data, i);
> > -const char *tmp;
> > -
> > -if (!(tmp = virJSONValueGetString(child))) {
> > -virReportError(VIR_ERR_INTERNAL_ERROR,
> > -   _("%s array element does not contain data"),
> > -   qmpCmd);
> > -goto cleanup;
> > -}
> > -
> > -list[i] = g_strdup(tmp);
> > -}
> > -
> > -ret = n;
> > -*array = list;
> > -list = NULL;
> > +list = virJSONValueObjectGetStringArray(reply, "return");
>
> We can ditch the @list variable and assign to *array directly.
>
> > +if (!list)
> > +goto cleanup;
> > +ret = g_strv_length(list);
> > +*array = g_steal_pointer();
> >
> >cleanup:
> > -g_strfreev(list);
> >   virJSONValueFree(cmd);
> >   virJSONValueFree(reply);
> >   return ret;
> >
>
>
> How about this squashed in:
>
>
> diff --git c/src/qemu/qemu_monitor_json.c i/src/qemu/qemu_monitor_json.c
> index 3588a0c426..e7aa6b6ffd 100644
> --- c/src/qemu/qemu_monitor_json.c
> +++ i/src/qemu/qemu_monitor_json.c
> @@ -7533,7 +7533,6 @@ qemuMonitorJSONGetStringArray(qemuMonitorPtr mon,
> const char *qmpCmd,
>   int ret = -1;
>   virJSONValuePtr cmd;
>   virJSONValuePtr reply = NULL;
> -g_auto(GStrv) list = NULL;
>
>   *array = NULL;
>
> @@ -7551,11 +7550,10 @@ qemuMonitorJSONGetStringArray(qemuMonitorPtr
> mon, const char *qmpCmd,
>   if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_ARRAY) < 0)
>   goto cleanup;
>
> -list = virJSONValueObjectGetStringArray(reply, "return");
> -if (!list)
> +if (!(*array = virJSONValueObjectGetStringArray(reply, "return")))
>   goto cleanup;
> -ret = g_strv_length(list);
> -*array = g_steal_pointer();
> +
> +ret = g_strv_length(*array);
>
>cleanup:
>   virJSONValueFree(cmd);
>

Looks good to me, thanks

Re: [libvirt PATCH 0/9] qemu: report guest disks informations

[Marc-André Lureau]

On Fri, Nov 20, 2020 at 10:10 PM  wrote:

> From: Marc-André Lureau 
>
> Hi,
>
> The following series extends virDomainGetGuestInfo to report disk
> informations
> provided by the new QGA "guest-get-disks" command in QEMU 5.2.
>
> Please review,
>

ping


> Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1899527
>
> Marc-André Lureau (9):
>   qemu_agent: rename qemuAgentDiskInfo->qemuAgentDiskAddress
>   qemu_agent: export qemuAgentDiskAddressFree & add g_auto
>   qemu_agent: factor out qemuAgentGetDiskAddress
>   util: json: add virJSONValueObjectGetStringArray convenience
>   qemu: use virJSONValueObjectGetStringArray
>   qemu_agent: add qemuAgentGetDisks
>   domain: add disk informations to virDomainGetGuestInfo
>   qemu_driver: report guest disk informations
>   virsh: add --disk informations to guestinfo command
>
>  include/libvirt/libvirt-domain.h |   1 +
>  src/libvirt-domain.c |  17 +++
>  src/libvirt_private.syms |   1 +
>  src/qemu/qemu_agent.c| 182 +++
>  src/qemu/qemu_agent.h|  25 -
>  src/qemu/qemu_driver.c   | 103 -
>  src/qemu/qemu_monitor_json.c |  34 +-
>  src/util/virjson.c   |  30 +
>  src/util/virjson.h   |   1 +
>  tests/qemuagenttest.c| 111 +++
>  tools/virsh-domain.c |   6 +
>  11 files changed, 430 insertions(+), 81 deletions(-)
>
> --
> 2.29.0
>
>
>

-- 
Marc-André Lureau

Re: [libvirt PATCH] qemu: add qemuAgentSSH{Add, Remove, Get}AuthorizedKeys

[Marc-André Lureau]

Hi

On Mon, Nov 9, 2020 at 4:44 PM Michal Privoznik  wrote:
>
> I'm stopping my review here. The wrappers are okay, but we really need
> the public API and RPC first. I can work on that if you don't feel like it.

I am on holiday this week and perhaps a few more days. If you have
some free time, feel free to update the patch. Otherwise, it will wait
a bit longer.

thanks

Re: [PATCH v5 0/3] tpm: Fix default choices for CRB and SPAPR dev models

[Marc-André Lureau]

Hi

On Fri, Jul 10, 2020 at 12:49 AM Stefan Berger 
wrote:

> From: Stefan Berger 
>
> This series of patches adds an additional check for the SPAPR device model
> that prevents the choice of a TPM 1.2 backend and chooses a TPM 2 as
> default.
> Also CRB now chooses a TPM 2 as default since TPM 1.2 wouldn't work with
> it,
> either.
>
>Stefan
>
> v4->v5:
>   - Added R-b's
>
> Stefan Berger (3):
>   qemu: Move setting of TPM default to post parse function
>   qemu: Set SPAPR TPM default to 2.0 and prevent 1.2 choice
>   qemu: Choose TPM 2 for backend as default for CRB interface
>

Series:
Reviewed-by: Marc-André Lureau 


>  src/qemu/qemu_domain.c   | 12 +---
>  src/qemu/qemu_validate.c | 10 ++
>  2 files changed, 15 insertions(+), 7 deletions(-)
>
> --
> 2.17.1
>
>

-- 
Marc-André Lureau

Re: [libvirt PATCH 1/6] slirp: leave the dbus daemon running on error

[Marc-André Lureau]

Hi

On Tue, Apr 21, 2020 at 7:42 PM Michal Privoznik  wrote:
>
> On 4/21/20 6:50 PM, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Apr 21, 2020 at 6:04 PM Michal Privoznik  
> > wrote:
> >>
> >> On 4/8/20 7:23 PM, marcandre.lur...@redhat.com wrote:
> >>> From: Marc-André Lureau 
> >>>
> >>> Don't stop the DBus daemon if a slirp helper failed to start, as it
> >>> may be shared with other helpers.
> >>>
> >>> Signed-off-by: Marc-André Lureau 
> >>> ---
> >>>src/qemu/qemu_slirp.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c
> >>> index 09c1247892..49bffa01b8 100644
> >>> --- a/src/qemu/qemu_slirp.c
> >>> +++ b/src/qemu/qemu_slirp.c
> >>> @@ -355,6 +355,6 @@ qemuSlirpStart(qemuSlirpPtr slirp,
> >>>virProcessKillPainfully(pid, true);
> >>>if (pidfile)
> >>>unlink(pidfile);
> >>> -qemuDBusStop(driver, vm);
> >>> +/* leave dbus daemon running, it may be used by others */
> >>>return -1;
> >>>}
> >>>
> >>
> >> I'm not quite sure about this one. Who do you mean by "others"? Other
> >
> > Other users of DBus. For now, it's only slirp-helper, but there can be
> > already multiple instances.
>
> Ah, I've misunderstood this part. But if there is only one user of the
> DBus (us who are trying to start it now), shouldn't we kill the dbus
> daemon? On the other hand, it will be done by qemuProcessStop()
> eventually. My idea was to track whether the dbus daemon is running
> prior starting it (basically save priv->dbusDaemonRunning before calling
> qemuDBusStart() and then wrap this qemuDBusStop() with 'if
> (was_started)'. I can do the change before push, if you are okay with
> it. I just like functions to tidy up on failure, maybe it's just an
> obsession though.

Oh ok, that should be fine.
thanks

Re: [libvirt PATCH 1/6] slirp: leave the dbus daemon running on error

[Marc-André Lureau]

Hi

On Tue, Apr 21, 2020 at 6:04 PM Michal Privoznik  wrote:
>
> On 4/8/20 7:23 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Don't stop the DBus daemon if a slirp helper failed to start, as it
> > may be shared with other helpers.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_slirp.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c
> > index 09c1247892..49bffa01b8 100644
> > --- a/src/qemu/qemu_slirp.c
> > +++ b/src/qemu/qemu_slirp.c
> > @@ -355,6 +355,6 @@ qemuSlirpStart(qemuSlirpPtr slirp,
> >   virProcessKillPainfully(pid, true);
> >   if (pidfile)
> >   unlink(pidfile);
> > -qemuDBusStop(driver, vm);
> > +/* leave dbus daemon running, it may be used by others */
> >   return -1;
> >   }
> >
>
> I'm not quite sure about this one. Who do you mean by "others"? Other

Other users of DBus. For now, it's only slirp-helper, but there can be
already multiple instances.

> interfaces? Is this supposed to help with 3/6 so that if we attempt to
> double start the dbus daemon the second attempt doesn't actually kill
> the daemon started in the first attempt?

yes, the point is to have a single bus for the VM needs.

thanks

>
> ACK to the rest.
>
> Michal
>

Re: [libvirt PATCH 00/15] RFC: basic CGroup support with qemu:///session

[Marc-André Lureau]

Hi

On Tue, Apr 7, 2020 at 10:55 AM Pavel Hrdina  wrote:
>
> On Mon, Apr 06, 2020 at 11:26:57PM +0200, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Hi,
> >
> > This is a small series that allows basic QEMU VM CGroup support with
> > the help of machined --user:
> > https://github.com/systemd/systemd/pull/15312
> >
> > The first few patches are fixes to register dbus and slirp-helper
> > correctly with the VM cgroup.
> >
> > A few changes are done to the machined support, adding session
> > support, and registering the VM to get a systemd scope cgroup under
> > user machine.slice.
>
> Hi,
>
> Before we start with anything I would like to know what is the
> motivation behind having CGroup support for session VMs?

My initial motivation was to have a way to group VM processes and kill
them altogether, because I tend to have a lot of them around after a
while.

Given that systemd --user is very capable and based on
https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/,
I thought that was probably the way to go.

>
> From the systemd pull request it looks like you would like to have
> session VMs under the /sys/fs/cgroup/machine.slice which is completely
> wrong as we should not mix system and session VMs under the same slice.

No, it is under user.slice, ex with this series:

   CGroup: /user.slice/user-1000.slice/user@1000.service
   ├─machine.slice
   │ └─machine-qemu\x2delmarco\x2d1\x2dfedora.scope
   │   ├─24714 /usr/bin/swtpm socket --daemon --ctrl
type=unixio,path=/run/user/1000/libvirt/qemu/run/swtpm/1-fedora-swtpm.sock,mode=0600
--tpmstate dir=/home/elmarco/.config/libvirt/qemu/swtpm/053f84e7>
   │   ├─24716 /usr/bin/dbus-daemon
--config-file=/run/user/1000/libvirt/qemu/run/dbus/1-fedora-dbus.conf
   │   ├─24719
/home/elmarco/src/libslirp-rs/target/debug/libslirp-helper --fd=27
--dbus-id=slirp-52:54:00:9c:bb:6c
--dbus-address=unix:path=/run/user/1000/libvirt/qemu/run/dbus/1-fedora-dbus.sock
--exi>
   │   ├─24722 /usr/bin/qemu-system-x86_64 -name
guest=fedora,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/home/elmarco/.config/libvirt/qemu/lib/domain-1-fedora/master-key.aes
-obje>
   │   └─emulator

>
> In addition it would not work because because you would use session
> D-Bus which would start machined under user running session VM and that
> user will not have permissions to do anything with the system
> machine.slice.  If a regular user wants to do anything with cgroups
> delegation has to be used and obviously we cannot delegate the system
> machine.slice, it would have to live in a different location and since
> the QEMU process is running under the specific user it would have to
> live within /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/
> where by default only memory and pids controllers are available.
> Delegation would have to be set in order to get other controllers as
> well and all of this would work only if cgroups v2 are used.

I thought delegation was required too, but I can't see any "Delegate="
in my user machine cgroup tree. (using systemctl --user show - note
that /machine.slice doesn't have Delegate set either)

But you can see that basic process management works fine with the
systemd series proposed.

Yes, this is certainly cgroups v2 only.

thanks

Re: [libvirt PATCH 09/15] systemd: check org.freedesktop.machine1 registration

[Marc-André Lureau]

Hi

On Tue, Apr 7, 2020 at 11:50 AM Ján Tomko  wrote:
>
> On a Monday in 2020, marcandre.lur...@redhat.com wrote:
> >From: Marc-André Lureau 
> >
> >Since commit f10bd740e178c89f24d0b0298d0b5413537d0699 ("Cache the
> >presence of machine1 service"), the code checks for systemd1
> >registration. Not totally unreasonable, but that seems odd since we
> >actually check machined presence in this function.
>
> That is intentional.
>
> We only count the systemd-based services as really activatable
> if systemd1 is already registered.
>
> On some Frankenstein'd Gentoo systems with systemd installed
> but not started, the services were showing up as activatable
> but failed with obscure errors.
>
> Some history:
> commit 12ee0b98d3ddcb2c71cdb2352512153791ebcb7e
>  Check if systemd is running before creating machines
> https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=12ee0b98
> https://bugs.gentoo.org/show_bug.cgi?id=493246#c22

Ok, I imagined something like that. However, making systemd a
hard-dependency for machine1 is not a good solution. In theory,
machine1 could have a different implementation that doesn't rely on
systemd.

Re: [PATCH] news: Document recent dbus-vmstate changes

[Marc-André Lureau]

Hi

On Wed, Apr 1, 2020 at 6:40 PM Andrea Bolognani  wrote:
>
> On Wed, 2020-04-01 at 18:23 +0200, Michal Privoznik wrote:
> > +  
> > +
> > +  qemu: Support migration with SLIRP interface
> > +
> > +
> > +  As libslirp evolves, so does QEMU. The recent 
> > change is
> > +  that instead of peer-to-peer connection between QEMU and
> > +  slirp-helper process a separate D-BUS bus is 
> > created.
> > +  This enables QEMU to migrate with a SLIRP interface.
> > +
> > +  
>
> This looks reasonable enough to me, so
>
>   Reviewed-by: Andrea Bolognani 
>
> but let's maybe wait until tomorrow to push, in order to give
> Marc-André a chance to speak his mind.

Thanks. That's quite accurate, but it may be misinterpreted:

Networking data is still going through a 1-1 dgram unix socket.

D-Bus bus is used to communicate with the helper for RPC/management,
including migration.

After discussions, we decided to switch to a bus, as it permits other
tools, such as libvirt or others, to interact with the helpers easily.
A bus topology reduces the overall complexity for implementation and
debugging. This should slowly become the RPC standard for
"multi-process qemu"  in general. So libvirt will need a single
connection to the bus, and can then talk to the various helper
processes. Similarly for qemu or third-party (with security
restrictions).

Since the p2p dbus support was never actually used, I am not sure we
need to explain that there was a transition. Let me suggest:

qemu: Support migration with SLIRP helper interface

With QEMU 5.0, a new D-Bus backend allows migration of external
processes. When needed, libvirt will start a per-vm D-Bus bus, and
migrate the slirp-helper along with QEMU.

my 2c

Re: [PATCH] qemu-shim: add a --with-config option

[Marc-André Lureau]

Hi

On Mon, Mar 30, 2020 at 1:54 PM Daniel P. Berrangé  wrote:
>
> On Sat, Mar 28, 2020 at 12:38:57AM +0100, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Add an option to ease setting up a VM with existing libvirt qemu.conf.
> >
> > Fixes:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1817776
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  docs/manpages/virt-qemu-run.rst |  6 ++
> >  src/libvirt_private.syms|  1 -
> >  src/qemu/qemu_shim.c| 36 +
> >  3 files changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/manpages/virt-qemu-run.rst 
> > b/docs/manpages/virt-qemu-run.rst
> > index b06c311b1d..3196b4c8f4 100644
> > --- a/docs/manpages/virt-qemu-run.rst
> > +++ b/docs/manpages/virt-qemu-run.rst
> > @@ -71,6 +71,12 @@ is a path to the XML description of the secret, whose 
> > UUID should
> >  match a secret referenced in the guest domain XML. The ``VALUE-FILE``
> >  is a path containing the raw value of the secret.
> >
> > +``-c``, ``--with-config``
> > +
> > +Copy the libvirt qemu.conf configuration to the root directory.  If
> > +there is already a qemu.conf file in the $ROOT/etc directory, exit
> > +with failure.
>
> As discussed in the bugzilla, we really don't want to be using the
> global qemu.conf file in combination with the embedded driver. We
> are not intending to guarantee that the embedded driver will share
> the same defaults as the global drivers.
>
> In general we want to eliminate the need to touch qemu.conf at all.

With qemu:///embed, is the $root/etc/qemu.conf supposed to be user configurable?

If not, then it should not even be accessed.

Otherwise, having an option to ease setting it up would be welcome! If
not from the user/system libvirt config, from a given path (for me, it
will likely always be my user libvirt config anyway)

Re: [PATCH] util: virdaemon: fix compilation on mingw

[Marc-André Lureau]

On Fri, Mar 27, 2020 at 6:41 PM Rafael Fonseca  wrote:
>
> The daemons are not supported on Win32 and therefore were not compiled
> in that platform. However, with the daemon code sharing, all the code in
> utils *is* compiled and it failed because `waitpid`, `fork`, and
> `setsid` are not available. So, as before, let's not build them on
> Win32 and make the code more portable by using existing vir* wrappers.
>
> Signed-off-by: Rafael Fonseca 

Reviewed-by: Marc-André Lureau 


> ---
>  src/util/virdaemon.c | 46 +++-
>  1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/src/util/virdaemon.c b/src/util/virdaemon.c
> index 789adc6c50..5d92c7def7 100644
> --- a/src/util/virdaemon.c
> +++ b/src/util/virdaemon.c
> @@ -20,9 +20,7 @@
>
>  #include 
>
> -#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -32,9 +30,13 @@
>  #include "virfile.h"
>  #include "virlog.h"
>  #include "viralloc.h"
> +#include "virprocess.h"
> +#include "vircommand.h"
>
>  #include "configmake.h"
>
> +#ifndef WIN32
> +
>  int
>  virDaemonForkIntoBackground(const char *argv0)
>  {
> @@ -42,7 +44,7 @@ virDaemonForkIntoBackground(const char *argv0)
>  if (virPipeQuiet(statuspipe) < 0)
>  return -1;
>
> -pid_t pid = fork();
> +pid_t pid = virFork();
>  switch (pid) {
>  case 0:
>  {
> @@ -71,7 +73,7 @@ virDaemonForkIntoBackground(const char *argv0)
>  if (setsid() < 0)
>  goto cleanup;
>
> -nextpid = fork();
> +nextpid = virFork();
>  switch (nextpid) {
>  case 0: /* grandchild */
>  return statuspipe[1];
> @@ -102,7 +104,7 @@ virDaemonForkIntoBackground(const char *argv0)
>  VIR_FORCE_CLOSE(statuspipe[1]);
>
>  /* We wait to make sure the first child forked successfully */
> -if ((got = waitpid(pid, , 0)) < 0 ||
> +if ((got = virProcessWait(pid, , 0)) < 0 ||
>  got != pid ||
>  exitstatus != 0) {
>  goto error;
> @@ -250,3 +252,37 @@ virDaemonUnixSocketPaths(const char *sock_prefix,
>  VIR_FREE(rundir);
>  return ret;
>  }
> +
> +#else /* WIN32 */
> +
> +int virDaemonForkIntoBackground(const char *argv0 G_GNUC_UNUSED)
> +{
> +errno = ENOTSUP;
> +return -1;
> +}
> +
> +void virDaemonSetupLogging(const char *daemon_name G_GNUC_UNUSED,
> +   unsigned int log_level G_GNUC_UNUSED,
> +   char *log_filters G_GNUC_UNUSED,
> +   char *log_outputs G_GNUC_UNUSED,
> +   bool privileged G_GNUC_UNUSED,
> +   bool verbose G_GNUC_UNUSED,
> +   bool godaemon G_GNUC_UNUSED)
> +{
> +/* NOOP */
> +errno = ENOTSUP;
> +return;
> +}
> +
> +int virDaemonUnixSocketPaths(const char *sock_prefix G_GNUC_UNUSED,
> + bool privileged G_GNUC_UNUSED,
> +         char *unix_sock_dir G_GNUC_UNUSED,
> + char **sockfile G_GNUC_UNUSED,
> + char **rosockfile G_GNUC_UNUSED,
> + char **adminSockfile G_GNUC_UNUSED)
> +{
> +errno = ENOTSUP;
> +return -1;
> +}
> +
> +#endif /* WIN32 */
> --
> 2.25.1
>
>


-- 
Marc-André Lureau

Re: [PATCH RESEND 2/5] qemuProcessStartManagedPRDaemon: Don't pass -f pidfile to the daemon

[Marc-André Lureau]

Hi

On Mon, Mar 23, 2020 at 6:48 PM Michal Prívozník  wrote:
>
> On 23. 3. 2020 17:36, Marc-André Lureau wrote:
> > Hi
> >
> > On Mon, Mar 23, 2020 at 5:16 PM Michal Privoznik  
> > wrote:
> >>
> >> Now, that our virCommandSetPidFile() is more intelligent we don't
> >> need to rely on the daemon to create and lock the pidfile and use
> >> virCommandSetPidFile() at the same time.
> >>
> >> Signed-off-by: Michal Privoznik 
> >
> > Nice, but doesn't this also fix a temporary regression introduced by
> > previous commit, now that pidfile is locked?
>
> Yeah, I haven't found a way to do this regression free.

Either squash them,

Or add a fat warning on the previous commit, and mention that you fix
it here too.

With that,
Reviewed-by: Marc-André Lureau 



-- 
Marc-André Lureau

Re: [PATCH RESEND 1/5] virCommand: Actually acquire pidfile instead of just writing it

[Marc-André Lureau]

Hi


On Mon, Mar 23, 2020 at 5:14 PM Michal Privoznik  wrote:
>
> Our virCommand module allows us to set a pidfile for commands we
> want to spawn. The caller constructs the string of pidfile path
> and then uses virCommandSetPidFile() to tell the module to write
> the pidfile once the command is ran. This usually works, but has
> two flaws:
>
> 1) the child process does not hold the pidfile open & locked.
> Therefore, the caller (or anybody else) can't use our fancy
> virPidFileForceCleanupPath() function to kill the command
> afterwards. Also, for everybody else on the system it's
> needlessly harder to check if the pid from the pidfile is still
> alive or not.
>
> 2) if the caller ever makes a mistake and passes the same pidfile
> path for two different commands, the start of the second command
> will overwrite the pidfile even though the first command might
> still be running.
>
> Signed-off-by: Michal Privoznik 

Reviewed-by: Marc-André Lureau 


> ---
>  docs/internals/command.html.in |  4 ++-
>  src/util/vircommand.c  | 56 +-
>  tests/commanddata/test4.log|  1 +
>  3 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/docs/internals/command.html.in b/docs/internals/command.html.in
> index 8a9061e70f..823d89cc71 100644
> --- a/docs/internals/command.html.in
> +++ b/docs/internals/command.html.in
> @@ -226,7 +226,9 @@ virCommandSetPidFile(cmd, "/var/run/dnsmasq.pid");
>
>  
>This PID file is guaranteed to be written before
> -  the intermediate process exits.
> +  the intermediate process exits. Moreover, the daemonized
> +  process will inherit the FD of the opened and locked PID
> +  file.
>  
>
>  Reducing command privileges
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 9ffa0cf49b..77078d09fb 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -612,6 +612,7 @@ virExec(virCommandPtr cmd)
>  int null = -1;
>  int pipeout[2] = {-1, -1};
>  int pipeerr[2] = {-1, -1};
> +int pipesync[2] = {-1, -1};
>  int childin = cmd->infd;
>  int childout = -1;
>  int childerr = -1;
> @@ -745,9 +746,15 @@ virExec(virCommandPtr cmd)
>  /* Initialize full logging for a while */
>  virLogSetFromEnv();
>
> +if (cmd->pidfile &&
> +virPipe(pipesync) < 0)
> +goto fork_error;
> +
>  /* Daemonize as late as possible, so the parent process can detect
>   * the above errors with wait* */
>  if (cmd->flags & VIR_EXEC_DAEMON) {
> +char c;
> +
>  if (setsid() < 0) {
>  virReportSystemError(errno,
>   "%s", _("cannot become session leader"));
> @@ -768,12 +775,13 @@ virExec(virCommandPtr cmd)
>  }
>
>  if (pid > 0) {
> -if (cmd->pidfile && (virPidFileWritePath(cmd->pidfile, pid) < 
> 0)) {
> -if (virProcessKillPainfully(pid, true) >= 0)
> -virReportSystemError(errno,
> - _("could not write pidfile %s for 
> %d"),
> - cmd->pidfile, pid);
> -goto fork_error;
> +/* The parent expect us to have written the pid file before
> + * exiting. Wait here for the child to write it and signal us. */
> +if (cmd->pidfile &&
> +saferead(pipesync[0], , sizeof(c)) != sizeof(c)) {
> +virReportSystemError(errno, "%s",
> + _("Unable to wait for child process"));
> +_exit(EXIT_FAILURE);
>  }
>  _exit(EXIT_SUCCESS);
>  }
> @@ -788,6 +796,37 @@ virExec(virCommandPtr cmd)
>  if (cmd->setMaxCore &&
>  virProcessSetMaxCoreSize(0, cmd->maxCore) < 0)
>  goto fork_error;
> +if (cmd->pidfile) {
> +VIR_AUTOCLOSE pidfilefd = -1;
> +int newpidfilefd = -1;
> +char c;
> +
> +pidfilefd = virPidFileAcquirePath(cmd->pidfile, false, getpid());
> +if (pidfilefd < 0)
> +goto fork_error;
> +if (virSetInherit(pidfilefd, true) < 0) {
> +virReportSystemError(errno, "%s",
> + _("Cannot disable close-on-exec flag"));
> +goto fork_error;
> +}
> +
> +c = '1';
> +if (safewrite(pipesync[1], , sizeof(c)) != sizeof(c)) {
> +virReportSyste

Re: [PATCH RESEND 5/5] bridge_driver: Replace and drop networkKillDaemon

[Marc-André Lureau]

n(radvdPid, "radvd", def->name) >= 0) &&
> -((radvdpidbase = networkRadvdPidfileBasename(def->name))
> - != NULL)) {
> -virPidFileDelete(driver->pidDir, radvdpidbase);
> -VIR_FREE(radvdpidbase);
> +if ((radvdpidbase = networkRadvdPidfileBasename(def->name)) &&
> +(pidfile = virPidFileBuildPath(driver->pidDir, radvdpidbase))) {
> +/* radvd should not be running but in case it is */
> +virPidFileForceCleanupPath(pidfile);
> +virNetworkObjSetRadvdPid(obj, -1);
>  }


I doubt def->name can be NULL, thus all the if conditions seems
misleading to me. I guess the code inherits OOM handling.


> -virNetworkObjSetRadvdPid(obj, -1);
>  return 0;
>  }
>  virObjectUnref(dnsmasq_caps);
> @@ -2110,23 +2044,19 @@ static int
>  networkRestartRadvd(virNetworkObjPtr obj)
>  {
>  virNetworkDefPtr def = virNetworkObjGetDef(obj);
> -char *radvdpidbase;
> -pid_t radvdPid = virNeworkObjGetRadvdPid(obj);
> +g_autofree char *radvdpidbase = NULL;
> +g_autofree char *pidfile = NULL;
>
> -/* if there is a running radvd, kill it */
> -if (radvdPid > 0) {
> -/* essentially ignore errors from the following two functions,
> - * since there's really no better recovery to be done than to
> - * just push ahead (and that may be exactly what's needed).
> - */
> -if ((networkKillDaemon(radvdPid, "radvd", def->name) >= 0) &&
> -((radvdpidbase = networkRadvdPidfileBasename(def->name))
> - != NULL)) {
> -virPidFileDelete(driver->pidDir, radvdpidbase);
> -VIR_FREE(radvdpidbase);
> -}
> +/* If there is a running radvd, kill it. Essentially ignore errors from 
> the
> + * following two functions, since there's really no better recovery to be
> + * done than to just push ahead (and that may be exactly what's needed).
> + */
> +if ((radvdpidbase = networkRadvdPidfileBasename(def->name)) &&
> +(pidfile = virPidFileBuildPath(driver->pidDir, radvdpidbase))) {
> +virPidFileForceCleanupPath(pidfile);
>  virNetworkObjSetRadvdPid(obj, -1);
>  }
> +
>  /* now start radvd if it should be started */
>  return networkStartRadvd(obj);
>  }
> --
> 2.24.1
>

Reviewed-by: Marc-André Lureau 


-- 
Marc-André Lureau

Re: [PATCH RESEND 3/5] qemuSlirpStop: Simplify helper kill

[Marc-André Lureau]

On Mon, Mar 23, 2020 at 5:14 PM Michal Privoznik  wrote:
>
> Now, that we know that the slirp helper will have the pidfile
> open and locked we can use virPidFileForceCleanupPath() to kill
> it and unlink the pidfile.
>
> Signed-off-by: Michal Privoznik 

Reviewed-by: Marc-André Lureau 


> ---
>  src/qemu/qemu_slirp.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c
> index 5266b36eaa..be586ade12 100644
> --- a/src/qemu/qemu_slirp.c
> +++ b/src/qemu/qemu_slirp.c
> @@ -246,8 +246,6 @@ qemuSlirpStop(qemuSlirpPtr slirp,
>  g_autofree char *dbus_path = NULL;
>  g_autofree char *id = qemuSlirpGetDBusVMStateId(net);
>  virErrorPtr orig_err;
> -pid_t pid;
> -int rc;
>
>  if (!(pidfile = qemuSlirpCreatePidFilename(cfg, vm->def, 
> net->info.alias))) {
>  VIR_WARN("Unable to construct slirp pidfile path");
> @@ -261,17 +259,11 @@ qemuSlirpStop(qemuSlirpPtr slirp,
>  }
>
>  virErrorPreserveLast(_err);
> -rc = virPidFileReadPathIfAlive(pidfile, , cfg->slirpHelperName);
> -if (rc >= 0 && pid != (pid_t) -1)
> -virProcessKillPainfully(pid, true);
> -
> -if (unlink(pidfile) < 0 &&
> -errno != ENOENT) {
> -virReportSystemError(errno,
> - _("Unable to remove stale pidfile %s"),
> - pidfile);
> +if (virPidFileForceCleanupPath(pidfile) < 0) {
> +VIR_WARN("Unable to kill slirp process");
> +} else {
> +    slirp->pid = 0;
>  }
> -slirp->pid = 0;
>
>  dbus_path = qemuSlirpGetDBusPath(cfg, vm->def, net->info.alias);
>  if (dbus_path) {
> --
> 2.24.1
>


-- 
Marc-André Lureau

Re: [PATCH RESEND 4/5] qemuVirtioFSStop: Simplify daemon kill

[Marc-André Lureau]

On Mon, Mar 23, 2020 at 5:14 PM Michal Privoznik  wrote:
>
> Now, that we know that the virtiofsd will have the pidfile open
> and locked we can use virPidFileForceCleanupPath() to kill it and
> unlink the pidfile.
>
> Signed-off-by: Michal Privoznik 

Reviewed-by: Marc-André Lureau 


> ---
>  src/qemu/qemu_virtiofs.c | 21 +++--
>  1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c
> index d579ce1d33..bbe93e0186 100644
> --- a/src/qemu/qemu_virtiofs.c
> +++ b/src/qemu/qemu_virtiofs.c
> @@ -36,6 +36,8 @@
>
>  #define VIR_FROM_THIS VIR_FROM_QEMU
>
> +VIR_LOG_INIT("qemu.virtiofs");
> +
>
>  char *
>  qemuVirtioFSCreatePidFilename(virDomainObjPtr vm,
> @@ -275,28 +277,19 @@ qemuVirtioFSStop(virQEMUDriverPtr driver G_GNUC_UNUSED,
>  {
>  g_autofree char *pidfile = NULL;
>  virErrorPtr orig_err;
> -pid_t pid = -1;
> -int rc;
>
>  virErrorPreserveLast(_err);
>
>  if (!(pidfile = qemuVirtioFSCreatePidFilename(vm, fs->info.alias)))
>  goto cleanup;
>
> -rc = virPidFileReadPathIfAlive(pidfile, , NULL);
> -if (rc >= 0 && pid != (pid_t) -1)
> -virProcessKillPainfully(pid, true);
> -
> -if (unlink(pidfile) < 0 &&
> -errno != ENOENT) {
> -virReportSystemError(errno,
> - _("Unable to remove stale pidfile %s"),
> - pidfile);
> +if (virPidFileForceCleanupPath(pidfile) < 0) {
> +VIR_WARN("Unable to kill virtiofsd process");
> +} else {
> +if (QEMU_DOMAIN_FS_PRIVATE(fs)->vhostuser_fs_sock)
> +unlink(QEMU_DOMAIN_FS_PRIVATE(fs)->vhostuser_fs_sock);
>  }
>
> -if (QEMU_DOMAIN_FS_PRIVATE(fs)->vhostuser_fs_sock)
> -unlink(QEMU_DOMAIN_FS_PRIVATE(fs)->vhostuser_fs_sock);
> -
>   cleanup:
>  virErrorRestore(_err);
>  }
> --
> 2.24.1
>


-- 
Marc-André Lureau

Re: [PATCH RESEND 2/5] qemuProcessStartManagedPRDaemon: Don't pass -f pidfile to the daemon

[Marc-André Lureau]

Hi

On Mon, Mar 23, 2020 at 5:16 PM Michal Privoznik  wrote:
>
> Now, that our virCommandSetPidFile() is more intelligent we don't
> need to rely on the daemon to create and lock the pidfile and use
> virCommandSetPidFile() at the same time.
>
> Signed-off-by: Michal Privoznik 

Nice, but doesn't this also fix a temporary regression introduced by
previous commit, now that pidfile is locked?

> ---
>  src/qemu/qemu_process.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index e8401030a2..0324857913 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2850,7 +2850,6 @@ qemuProcessStartManagedPRDaemon(virDomainObjPtr vm)
>  g_autoptr(virQEMUDriverConfig) cfg = NULL;
>  int errfd = -1;
>  g_autofree char *pidfile = NULL;
> -int pidfd = -1;
>  g_autofree char *socketPath = NULL;
>  pid_t cpid = -1;
>  g_autoptr(virCommand) cmd = NULL;
> @@ -2869,10 +2868,6 @@ qemuProcessStartManagedPRDaemon(virDomainObjPtr vm)
>  if (!(pidfile = qemuProcessBuildPRHelperPidfilePath(vm)))
>  goto cleanup;
>
> -/* Just try to acquire. Dummy pid will be replaced later */
> -if ((pidfd = virPidFileAcquirePath(pidfile, false, -1)) < 0)
> -goto cleanup;
> -
>  if (!(socketPath = qemuDomainGetManagedPRSocketPath(priv)))
>  goto cleanup;
>
> @@ -2887,13 +2882,10 @@ qemuProcessStartManagedPRDaemon(virDomainObjPtr vm)
>
>  if (!(cmd = virCommandNewArgList(cfg->prHelperName,
>   "-k", socketPath,
> - "-f", pidfile,
>   NULL)))
>  goto cleanup;
>
>  virCommandDaemonize(cmd);
> -/* We want our virCommand to write child PID into the pidfile
> - * so that we can read it even before exec(). */
>  virCommandSetPidFile(cmd, pidfile);
>  virCommandSetErrorFD(cmd, );
>
> @@ -2956,7 +2948,6 @@ qemuProcessStartManagedPRDaemon(virDomainObjPtr vm)
>      if (pidfile)
>  unlink(pidfile);
>  }
> -VIR_FORCE_CLOSE(pidfd);
>  VIR_FORCE_CLOSE(errfd);
>  return ret;
>  }
> --
> 2.24.1
>


-- 
Marc-André Lureau

Re: [PATCH v4 00/34] Configurable policy for handling deprecated interfaces

[Marc-André Lureau]

son   |  30 +-
>  qapi/char.json|   1 +
>  qapi/compat.json  |  52 ++
>  qapi/control.json |  11 +-
>  qapi/introspect.json  |  28 +-
>  qapi/machine.json |  34 +-
>  qapi/migration.json   |  36 +-
>  qapi/misc.json|  13 +-
>  qapi/qapi-schema.json |   1 +
>  include/qapi/compat-policy.h  |  20 +
>  include/qapi/qmp/dispatch.h   |   1 +
>  include/qapi/qobject-input-visitor.h  |   9 +
>  include/qapi/qobject-output-visitor.h |   9 +
>  include/qapi/visitor-impl.h   |   3 +
>  include/qapi/visitor.h|   9 +
>  monitor/monitor-internal.h|   3 -
>  monitor/misc.c|   2 -
>  monitor/qmp-cmds-control.c| 102 +++-
>  qapi/qapi-visit-core.c|   9 +
>  qapi/qmp-dispatch.c   | 149 +++---
>  qapi/qobject-input-visitor.c  |  29 ++
>  qapi/qobject-output-visitor.c |  20 +
>  qemu-storage-daemon.c |   2 -
>  softmmu/vl.c  |  17 +
>  tests/test-qmp-cmds.c | 249 +
>  tests/test-qmp-event.c| 203 +++-
>  qapi/Makefile.objs|   8 +-
>  qapi/trace-events |   1 +
>  qemu-options.hx   |  22 +
>  scripts/qapi/commands.py  |  20 +-
>  scripts/qapi/doc.py   |  16 +-
>  scripts/qapi/events.py|  24 +-
>  scripts/qapi/expr.py  |  14 +-
>  scripts/qapi/introspect.py| 104 ++--
>  scripts/qapi/schema.py| 488 ++
>  scripts/qapi/types.py |   8 +-
>  scripts/qapi/visit.py |  28 +-
>  tests/Makefile.include|   1 +
>  tests/qapi-schema/alternate-base.err  |   2 +-
>  tests/qapi-schema/doc-good.json   |  22 +-
>  tests/qapi-schema/doc-good.out|  18 +
>  .../qapi-schema/features-deprecated-type.err  |   2 +
>  .../qapi-schema/features-deprecated-type.json |   3 +
>  .../qapi-schema/features-deprecated-type.out  |   0
>  tests/qapi-schema/qapi-schema-test.json   |  51 +-
>  tests/qapi-schema/qapi-schema-test.out|  48 +-
>  tests/qapi-schema/test-qapi.py|  26 +-
>  51 files changed, 1393 insertions(+), 762 deletions(-)
>  create mode 100644 qapi/compat.json
>  create mode 100644 include/qapi/compat-policy.h
>  create mode 100644 tests/qapi-schema/features-deprecated-type.err
>  create mode 100644 tests/qapi-schema/features-deprecated-type.json
>  create mode 100644 tests/qapi-schema/features-deprecated-type.out
>
> --
> 2.21.1
>


-- 
Marc-André Lureau

Re: [libvirt PATCH v2 0/9] Second take on slirp-helper & dbus-vmstate

[Marc-André Lureau]

On Tue, Feb 25, 2020 at 10:55 AM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> The series "[libvirt] [PATCH v2 00/23] Use a slirp helper process" has
> been merged and partially reverted. Meanwhile, qemu dbus-vmstate
> design has been changed and merged upstream.
>
> This new series fixes the slirp-helper support. The significant change
> is that dbus-vmstate now requires a bus (instead of the earlier
> peer-to-peer connection). The current series doesn't attempt to
> enforce strict policies on the bus. As long as you can connect to the
> bus, you can send/receive from/to anyone. A follow-up series should
> implement the recommendations from
> https://qemu.readthedocs.io/en/latest/interop/dbus.html#security.
>
> The libslirp-rs slirp-helper hasn't yet received an official release.
> For testing, you may:
> $ cargo install --features=all --git 
> https://gitlab.freedesktop.org/slirp/libslirp-rs
>
> The resulting binary should be ~/.cargo/bin/slirp-helper, so qemu.conf
> slirp_helper location should be adjusted. With that in place, a VM
> with user networking (slirp) should now start with the helper process.
>
> thanks
>
> v2:
> - merge most suggestions/changes from Michal Privoznik review of v1.
> - added "WIP: qemu_slirp: update to follow current spec"
>
> Marc-André Lureau (9):
>   qemu: remove dbus-vmstate code
>   qemu-conf: add configurable dbus-daemon location
>   qemu-conf: add dbusStateDir
>   qemu: add a DBus daemon helper unit
>   domain: save/restore the state of dbus-daemon running
>   qemu: prepare and stop the dbus daemon
>   qemu: add dbus-vmstate helper migration support
>   qemu-slirp: register helper for migration
>   WIP: qemu-slirp: update to follow current spec
>

ping ?
thanks

>  m4/virt-driver-qemu.m4 |   6 +
>  src/qemu/libvirtd_qemu.aug |   1 +
>  src/qemu/qemu.conf |   3 +
>  src/qemu/qemu_alias.c  |  17 +-
>  src/qemu/qemu_alias.h  |   3 +-
>  src/qemu/qemu_command.c|  81 +++--
>  src/qemu/qemu_command.h|   6 +-
>  src/qemu/qemu_conf.c   |   7 +
>  src/qemu/qemu_conf.h   |   2 +
>  src/qemu/qemu_dbus.c   | 264 +
>  src/qemu/qemu_dbus.h   |  25 ++-
>  src/qemu/qemu_domain.c |  30 ++--
>  src/qemu/qemu_domain.h |   8 +-
>  src/qemu/qemu_extdevice.c  |   4 +-
>  src/qemu/qemu_hotplug.c| 165 +-
>  src/qemu/qemu_hotplug.h|  17 +-
>  src/qemu/qemu_migration.c  |  57 ++-
>  src/qemu/qemu_monitor.c|  21 +++
>  src/qemu/qemu_monitor.h|   3 +
>  src/qemu/qemu_monitor_json.c   |  15 ++
>  src/qemu/qemu_monitor_json.h   |   5 +
>  src/qemu/qemu_process.c|   6 +
>  src/qemu/qemu_slirp.c  | 157 +++--
>  src/qemu/qemu_slirp.h  |   4 +-
>  src/qemu/test_libvirtd_qemu.aug.in |   1 +
>  25 files changed, 544 insertions(+), 364 deletions(-)
>
> --
> 2.25.0.rc2.1.g09a9a1a997
>


-- 
Marc-André Lureau

Re: [PATCH 3/8] qemu-conf: add dbusStateDir

[Marc-André Lureau]

Hi

On Tue, Feb 25, 2020 at 12:24 PM Michal Privoznik  wrote:
>
> On 2/24/20 4:57 PM, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  
> > wrote:
> >>
> >> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> >>> From: Marc-André Lureau 
> >>>
> >>> Location of DBus daemon state configuration, socket, pid...
> >>>
> >>> Signed-off-by: Marc-André Lureau 
> >>> ---
> >>>src/qemu/qemu_conf.c | 4 
> >>>src/qemu/qemu_conf.h | 1 +
> >>>2 files changed, 5 insertions(+)
> >>>
> >>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> >>> index e1fea390c7..ade12dac6c 100644
> >>> --- a/src/qemu/qemu_conf.c
> >>> +++ b/src/qemu/qemu_conf.c
> >>> @@ -144,6 +144,8 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> >>> privileged)
> >>>
> >>>cfg->cacheDir = g_strdup_printf("%s/cache/libvirt/qemu", 
> >>> LOCALSTATEDIR);
> >>>
> >>> +cfg->dbusStateDir = g_strdup_printf("%s/run/libvirt/qemu/dbus", 
> >>> LOCALSTATEDIR);
> >>> +
> >>>cfg->libDir = g_strdup_printf("%s/lib/libvirt/qemu", 
> >>> LOCALSTATEDIR);
> >>>cfg->saveDir = g_strdup_printf("%s/save", cfg->libDir);
> >>>cfg->snapshotDir = g_strdup_printf("%s/snapshot", cfg->libDir);
> >>> @@ -174,6 +176,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> >>> privileged)
> >>>cfg->stateDir = g_strdup_printf("%s/qemu/run", rundir);
> >>>
> >>>cfg->swtpmStateDir = g_strdup_printf("%s/swtpm", 
> >>> cfg->stateDir);
> >>> +cfg->dbusStateDir = g_strdup_printf("%s/dbus", cfg->stateDir);
> >>>
> >>>cfg->configBaseDir = virGetUserConfigDirectory();
> >>
> >> Instead of doing practically the same in two branches, you can achieve
> >> the same result with just one line if you put the call just below
> >> cfg->slirpStateDir init.
> >>
> >> However, do we need this to be in a special directory instead of per VM
> >> private directory? The way I implemented PR helper was that the socket
> >> it creates and to which qemu connects is stored under vm->priv->libDir
> >> which is initialized in qemuDomainSetPrivatePaths() to:
> >>
> >> $cfg->libDir/domain-$shortName/
> >>
> >> This way you wouldn't need to care about domain's shortname in the next
> >> patch.
> >
> > Makes sense. I think I based this on slirpStateDir code. Any reason
> > it's not using vm->priv->libdir too?
> >
>
> I don't know. But since there are some releases which would store data
> under slirpStateDir I don't think we can change this. On daemon restart
> (with newer version) the new libvirtd wouldn't see the old dir.

Actually, $cfg->libDir is virQEMUDriverConfigNew ()
cfg->configBaseDir/qemu/lib, so it ends up under ~/.config for users,
and /etc for priviledged/root. A bad place to store transient runtime
data/sockets. You may want to reconsider the paths for pr-helper.

I don't intend to change that, so you could take a look at "[libvirt
PATCH v2 0/9]".

Re: [libvirt PATCH v2 6/9] qemu: prepare and stop the dbus daemon

[Marc-André Lureau]

Hi

On Tue, Feb 25, 2020 at 12:49 PM Daniel P. Berrangé  wrote:
>
> On Tue, Feb 25, 2020 at 10:55:10AM +0100, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  src/qemu/qemu_process.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> > index 8c1ed76677..3a6cb4b2b0 100644
> > --- a/src/qemu/qemu_process.c
> > +++ b/src/qemu/qemu_process.c
> > @@ -58,6 +58,7 @@
> >  #include "qemu_extdevice.h"
> >  #include "qemu_firmware.h"
> >  #include "qemu_backup.h"
> > +#include "qemu_dbus.h"
> >
> >  #include "cpu/cpu.h"
> >  #include "cpu/cpu_x86.h"
> > @@ -6480,6 +6481,9 @@ qemuProcessPrepareHost(virQEMUDriverPtr driver,
> >  qemuDomainObjPrivatePtr priv = vm->privateData;
> >  g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver);
> >
> > +if (qemuDBusPrepareHost(driver) < 0)
> > +return -1;
>
> This launches dbus unconditionally for every VM regardless of whether
> its actually going to be used.

No, it is qemuDBusStart()

>
> There is certainly a nice conceptual simplicity in doing this, but
> I'm pretty concerned that there are going to be mgmt apps which
> do not like this extra overhead being added for every VM. I'm
> thinking KubeVirt and Kata containers in particular. This is also
> relevant for the libvirt embedded driver which is trying to eliminate
> all libvirt added overhead on managing QEMU, so that our fastest
> QEMU startup time can match that achieved by running QEMU directly.
> Unconditionally starting dbus will make that much more challenging.
>
> This is a long winded way of saying I think we need to do this
> only when it is actually required. This will certainly add complexity
> as we'll need to cope with dynamically launching DBus when we hotplug
> certain types of device which require it. I think we can ignore the
> hot-unplug case at least, as once you've taken the overhead for DBus
> for the VM, I don't think there's much to complain about, even if the
> device using it is unplugged.

It is done on-demand, by qemuSlirpStart() at the moment, and actually
only when the backend has dbus support.

Re: [libvirt] [PATCH 0/8] Second take on slirp-helper & dbus-vmstate

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
>
>
> Sorry for late review. I will reply to individual patches with suggested
> changes. I have them locally as a fixup patches, so I can squash them
> and resend (keeping your authorship of course). You can also find them
> on my branch (if you want to test them):
>
>https://github.com/zippy2/libvirt/commits/qemu_dbus_review

thanks for the review and the patches, I'll send a new version soon.

Re: [PATCH 2/8] qemu-conf: add configurable dbus-daemon location

[Marc-André Lureau]

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   m4/virt-driver-qemu.m4 | 6 ++
> >   src/qemu/libvirtd_qemu.aug | 1 +
> >   src/qemu/qemu.conf | 3 +++
> >   src/qemu/qemu_conf.c   | 5 +
> >   src/qemu/qemu_conf.h   | 1 +
> >   src/qemu/test_libvirtd_qemu.aug.in | 1 +
> >   6 files changed, 17 insertions(+)
> >
>
> > diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> > index b62dd1df52..e1fea390c7 100644
> > --- a/src/qemu/qemu_conf.c
> > +++ b/src/qemu/qemu_conf.c
> > @@ -228,6 +228,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> > privileged)
> >   cfg->bridgeHelperName = g_strdup(QEMU_BRIDGE_HELPER);
> >   cfg->prHelperName = g_strdup(QEMU_PR_HELPER);
> >   cfg->slirpHelperName = g_strdup(QEMU_SLIRP_HELPER);
> > +cfg->slirpHelperName = g_strdup(QEMU_DBUS_DAEMON);
>
> Oops, s/slirpHelperName/dbusDaemonName/  :-D
>

right, fixed

Re: [PATCH 7/8] qemu: add dbus-vmstate helper migration support

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Helper processes may have their state migrated with QEMU data stream
> > thanks to the QEMU "dbus-vmstate".
> >
> > libvirt maintains the list of helpers to be migrated. The
> > "dbus-vmstate" is added when required, and given the list of helper
> > Ids that must be migrated, on save & load sides.
> >
> > See also:
> > https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/dbus-vmstate.rst
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_alias.c|  7 +++
> >   src/qemu/qemu_alias.h|  2 +
> >   src/qemu/qemu_command.c  | 62 +++
> >   src/qemu/qemu_command.h  |  3 ++
> >   src/qemu/qemu_dbus.c | 14 ++
> >   src/qemu/qemu_dbus.h |  4 ++
> >   src/qemu/qemu_domain.c   | 10 +
> >   src/qemu/qemu_domain.h   |  5 +++
> >   src/qemu/qemu_hotplug.c  | 82 
> >   src/qemu/qemu_hotplug.h  |  8 
> >   src/qemu/qemu_migration.c| 51 ++
> >   src/qemu/qemu_monitor.c  | 21 +
> >   src/qemu/qemu_monitor.h  |  3 ++
> >   src/qemu/qemu_monitor_json.c | 15 +++
> >   src/qemu/qemu_monitor_json.h |  5 +++
> >   15 files changed, 292 insertions(+)
> >
>
>
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 71d0bb0879..8c281f3a70 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -1125,10 +1125,18 @@ qemuMigrationSrcIsAllowed(virQEMUDriverPtr driver,
> > bool remote,
> > unsigned int flags)
> >   {
> > +qemuDomainObjPrivatePtr priv = vm->privateData;
> >   int nsnapshots;
> >   int pauseReason;
> >   size_t i;
> >
> > +if (virStringListLength((const char **)priv->dbusVMStateIds) &&
> > +!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DBUS_VMSTATE)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> > +   _("cannot migrate this domain without dbus-vmstate 
> > support"));
> > +return false;
> > +}
> > +
>
> This should be done in the if(!OFFLINE) a few lines below. IIUC, vmstate
> is runtime thing, and when doing offline migration (e.g. just copying
> over disks and XMLs), no qemu is involved and thus no vmstate matters.

Right, thanks


>
> >   /* perform these checks only when migrating to remote hosts */
> >   if (remote) {
> >   nsnapshots = virDomainSnapshotObjListNum(vm->snapshots, NULL, 0);
>
> Michal
>

Re: [PATCH 8/8] qemu-slirp: register helper for migration

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > When the helper supports DBus, connect it to the bus and set its ID.
> >
> > If the helper supports migration, register its ID to the list of
> > dbus-vmstate ID to migrate, and specify --dbus-incoming when
> > restoring the VM.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_slirp.c | 37 +
> >   1 file changed, 37 insertions(+)
> >
> > diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c
> > index 8e001f0d10..48fc0a68c2 100644
> > --- a/src/qemu/qemu_slirp.c
> > +++ b/src/qemu/qemu_slirp.c
> > @@ -18,6 +18,7 @@
> >
> >   #include 
> >
> > +#include "qemu_dbus.h"
> >   #include "qemu_extdevice.h"
> >   #include "qemu_security.h"
> >   #include "qemu_slirp.h"
> > @@ -202,6 +203,16 @@ qemuSlirpGetFD(qemuSlirpPtr slirp)
> >   }
> >
> >
> > +static char *
> > +qemuSlirpGetDBusVMStateId(virDomainNetDefPtr net)
> > +{
> > +char macstr[VIR_MAC_STRING_BUFLEN] = "";
> > +
> > +/* can't use alias, because it's not stable across restarts */
> > +return g_strdup_printf("slirp-%s", virMacAddrFormat(>mac, 
> > macstr));
> > +}
> > +
> > +
> >   void
> >   qemuSlirpStop(qemuSlirpPtr slirp,
> > virDomainObjPtr vm,
> > @@ -209,11 +220,14 @@ qemuSlirpStop(qemuSlirpPtr slirp,
> > virDomainNetDefPtr net)
> >   {
> >   g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver);
> > +g_autofree char *id = qemuSlirpGetDBusVMStateId(net);
> >   g_autofree char *pidfile = NULL;
> >   virErrorPtr orig_err;
> >   pid_t pid;
> >   int rc;
> >
> > +qemuDBusVMStateRemove(vm, id);
> > +
> >   if (!(pidfile = qemuSlirpCreatePidFilename(cfg, vm->def, 
> > net->info.alias))) {
> >   VIR_WARN("Unable to construct slirp pidfile path");
> >   return;
> > @@ -310,6 +324,29 @@ qemuSlirpStart(qemuSlirpPtr slirp,
> >   }
> >   }
> >
> > +if (qemuSlirpHasFeature(slirp, QEMU_SLIRP_FEATURE_DBUS_ADDRESS)) {
> > +g_autofree char *id = qemuSlirpGetDBusVMStateId(net);
> > +g_autofree char *dbus_addr = qemuDBusGetAddress(driver, vm);
> > +
> > +if (qemuDBusStart(driver, vm) < 0)
> > +return -1;
> > +
> > +virCommandAddArgFormat(cmd, "--dbus-id=%s", id);
> > +
> > +virCommandAddArgFormat(cmd, "--dbus-address=%s", dbus_addr);
> > +
> > +if (qemuSlirpHasFeature(slirp, QEMU_SLIRP_FEATURE_MIGRATE)) {
> > +if (qemuDBusVMStateAdd(vm, id) < 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR,
> > +   _("Failed to register slirp migration"));
> > +return -1;
> > +}
> > +if (incoming) {
> > +virCommandAddArg(cmd, "--dbus-incoming");
> > +}
>
> 'make syntax-check' complains here.


thanks again for the fix!

Re: [PATCH 3/8] qemu-conf: add dbusStateDir

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Location of DBus daemon state configuration, socket, pid...
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_conf.c | 4 
> >   src/qemu/qemu_conf.h | 1 +
> >   2 files changed, 5 insertions(+)
> >
> > diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> > index e1fea390c7..ade12dac6c 100644
> > --- a/src/qemu/qemu_conf.c
> > +++ b/src/qemu/qemu_conf.c
> > @@ -144,6 +144,8 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> > privileged)
> >
> >   cfg->cacheDir = g_strdup_printf("%s/cache/libvirt/qemu", 
> > LOCALSTATEDIR);
> >
> > +cfg->dbusStateDir = g_strdup_printf("%s/run/libvirt/qemu/dbus", 
> > LOCALSTATEDIR);
> > +
> >   cfg->libDir = g_strdup_printf("%s/lib/libvirt/qemu", 
> > LOCALSTATEDIR);
> >   cfg->saveDir = g_strdup_printf("%s/save", cfg->libDir);
> >   cfg->snapshotDir = g_strdup_printf("%s/snapshot", cfg->libDir);
> > @@ -174,6 +176,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool 
> > privileged)
> >   cfg->stateDir = g_strdup_printf("%s/qemu/run", rundir);
> >
> >   cfg->swtpmStateDir = g_strdup_printf("%s/swtpm", cfg->stateDir);
> > +cfg->dbusStateDir = g_strdup_printf("%s/dbus", cfg->stateDir);
> >
> >   cfg->configBaseDir = virGetUserConfigDirectory();
>
> Instead of doing practically the same in two branches, you can achieve
> the same result with just one line if you put the call just below
> cfg->slirpStateDir init.
>
> However, do we need this to be in a special directory instead of per VM
> private directory? The way I implemented PR helper was that the socket
> it creates and to which qemu connects is stored under vm->priv->libDir
> which is initialized in qemuDomainSetPrivatePaths() to:
>
>$cfg->libDir/domain-$shortName/
>
> This way you wouldn't need to care about domain's shortname in the next
> patch.

Makes sense. I think I based this on slirpStateDir code. Any reason
it's not using vm->priv->libdir too?

Re: [PATCH 1/8] qemu: remove dbus-vmstate code

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > This code was based on a per-helper instance and peer-to-peer
> > connections. The code that landed in qemu master for v5.0 is relying
> > on a single instance and DBus bus.
> >
> > Instead of trying to adapt the existing dbus-vmstate code, let's
> > remove it and resubmit. That should make reviewing easier.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/Makefile.inc.am  |   2 -
> >   src/qemu/qemu_alias.c |  16 -
> >   src/qemu/qemu_alias.h |   3 -
> >   src/qemu/qemu_command.c   |  83 -
> >   src/qemu/qemu_command.h   |   3 -
> >   src/qemu/qemu_dbus.c  |  94 
> >   src/qemu/qemu_dbus.h  |  42 -
> >   src/qemu/qemu_domain.c|  13 
> >   src/qemu/qemu_domain.h|   1 -
> >   src/qemu/qemu_extdevice.c |   4 +-
> >   src/qemu/qemu_hotplug.c   |  83 +
> >   src/qemu/qemu_hotplug.h   |  11 
> >   src/qemu/qemu_migration.c |   8 ---
> >   src/qemu/qemu_slirp.c | 125 +-
> >   src/qemu/qemu_slirp.h |   4 +-
> >   15 files changed, 7 insertions(+), 485 deletions(-)
> >   delete mode 100644 src/qemu/qemu_dbus.c
> >   delete mode 100644 src/qemu/qemu_dbus.h
>
> You missed po/POTFILES.in:
>
> @SRCDIR@/src/qemu/qemu_dbus.c

yes, thanks

Re: [PATCH 4/8] qemu: add a DBus daemon helper unit

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Add a unit to start & stop a private dbus-daemon.
> >
> > The daemon is meant to be started on demand, and associated with a
> > QEMU process. It should be stopped when the QEMU process is stopped.
> >
> > The current policy is permissive like a session bus. Stricter
> > policies can be added later, following recommendations from:
> > https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/dbus.rst
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/Makefile.inc.am |   4 +
> >   src/qemu/qemu_dbus.c | 299 +++
> >   src/qemu/qemu_dbus.h |  40 ++
> >   src/qemu/qemu_domain.c   |   2 +
> >   src/qemu/qemu_domain.h   |   3 +
> >   tests/Makefile.am|   1 +
> >   6 files changed, 349 insertions(+)
> >   create mode 100644 src/qemu/qemu_dbus.c
> >   create mode 100644 src/qemu/qemu_dbus.h
> >
> > diff --git a/src/qemu/Makefile.inc.am b/src/qemu/Makefile.inc.am
> > index 028ab9043c..833638ec3c 100644
> > --- a/src/qemu/Makefile.inc.am
> > +++ b/src/qemu/Makefile.inc.am
> > @@ -69,6 +69,8 @@ QEMU_DRIVER_SOURCES = \
> >   qemu/qemu_checkpoint.h \
> >   qemu/qemu_backup.c \
> >   qemu/qemu_backup.h \
> > + qemu/qemu_dbus.c \
> > + qemu/qemu_dbus.h \
>
> These can be added where they were just a moment ago ;-)
>

yep

> >   $(NULL)
> >
> >
> > @@ -93,6 +95,7 @@ libvirt_driver_qemu_impl_la_CFLAGS = \
> >   $(LIBNL_CFLAGS) \
> >   $(SELINUX_CFLAGS) \
> >   $(XDR_CFLAGS) \
> > + $(DBUS_CFLAGS) \
> >   -I$(srcdir)/access \
> >   -I$(builddir)/access \
> >   -I$(srcdir)/conf \
> > @@ -105,6 +108,7 @@ libvirt_driver_qemu_impl_la_LIBADD = \
> >   $(GNUTLS_LIBS) \
> >   $(LIBNL_LIBS) \
> >   $(SELINUX_LIBS) \
> > + $(DBUS_LIBS) \
> >   $(LIBXML_LIBS) \
> >   $(NULL)
> >   libvirt_driver_qemu_impl_la_SOURCES = $(QEMU_DRIVER_SOURCES)
> > diff --git a/src/qemu/qemu_dbus.c b/src/qemu/qemu_dbus.c
> > new file mode 100644
> > index 00..9c8a03c947
> > --- /dev/null
> > +++ b/src/qemu/qemu_dbus.c
> > @@ -0,0 +1,299 @@
> > +/*
> > + * qemu_dbus.c: QEMU dbus daemon
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library.  If not, see
> > + * <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include 
> > +
> > +#include "qemu_extdevice.h"
> > +#include "qemu_dbus.h"
> > +#include "qemu_security.h"
> > +
> > +#include "viralloc.h"
> > +#include "virlog.h"
> > +#include "virstring.h"
> > +#include "virtime.h"
> > +#include "virpidfile.h"
> > +
> > +#define VIR_FROM_THIS VIR_FROM_NONE
> > +
> > +VIR_LOG_INIT("qemu.dbus");
> > +
> > +
> > +int
> > +qemuDBusPrepareHost(virQEMUDriverPtr driver)
> > +{
> > +virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
> > +
> > +return virDirCreate(cfg->dbusStateDir, 0770, cfg->user, cfg->group,
> > +VIR_DIR_CREATE_ALLOW_EXIST);
> > +}
> > +
> > +
> > +static char *
> > +qemuDBusCreatePidFilename(const char *stateDir,
> > +  const char *shortName)
> > +{
> > +g_autofree char *name = g_strdup_printf("%s-dbus", shortName);
> > +
> > +return virPidFileBuildPath(stateDir, name);
>
> Instead of having each caller pass cfg->dbusStateDir, we can accept cfg
> here and deref ourselves.

sure

>
> > +}
> > +
> > +
> > +static char *
> > +qemuDBusCreateFilename(const c

Re: [PATCH 5/8] domain: save/restore the state of dbus-daemon running

[Marc-André Lureau]

Hi

On Thu, Feb 20, 2020 at 10:04 AM Michal Privoznik  wrote:
>
> On 1/14/20 2:46 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > This avoids trying to start a dbus-daemon when its already running.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/qemu_domain.c | 5 +
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index 7722a53c62..dda3cb781f 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -2916,6 +2916,9 @@ qemuDomainObjPrivateXMLFormat(virBufferPtr buf,
> > 
> > virDomainChrTypeToString(priv->monConfig->type));
> >   }
> >
> > +if (priv->dbusDaemonRunning)
> > +virBufferAddLit(buf, "\n");
> > +
> >   if (priv->namespaces) {
> >   ssize_t ns = -1;
> >
> > @@ -3697,6 +3700,8 @@ qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt,
> >   goto error;
> >   }
> >
> > +priv->dbusDaemonRunning = virXPathBoolean("boolean(./dbusDaemon)", 
> > ctxt) > 0;
> > +
> >   if ((node = virXPathNode("./namespaces", ctxt))) {
> >   xmlNodePtr next;
> >
> >
>
> I'd push these a bit down - closer to PR daemon and slirp so that they
> are grouped together.

Well, as we introduce DBus bus for the VM, it would be a foundation
for IPC/multi-process communication, not specific to slirp. So I'd
leave it near the top.

Re: [libvirt] [PATCH 0/8] Second take on slirp-helper & dbus-vmstate

[Marc-André Lureau]

Hi

On Tue, Jan 14, 2020 at 2:47 PM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> The series "[libvirt] [PATCH v2 00/23] Use a slirp helper process" has
> been merged and partially reverted. Meanwhile, qemu dbus-vmstate
> design has been changed and merged upstream.
>
> This new series fixes the slirp-helper support. The significant change
> is that dbus-vmstate now requires a bus (instead of the earlier
> peer-to-peer connection). The current series doesn't attempt to
> enforce strict policies on the bus. As long as you can connect to the
> bus, you can send/receive from/to anyone. A follow-up series should
> implement the recommendations from
> https://qemu.readthedocs.io/en/latest/interop/dbus.html#security.
>
> The libslirp-rs slirp-helper hasn't yet received an official release.
> For testing, you may:
> $ cargo install --features=all --git 
> https://gitlab.freedesktop.org/slirp/libslirp-rs
>
> The resulting binary should be ~/.cargo/bin/slirp-helper, so qemu.conf
> slirp_helper location should be adjusted. With that in place, a VM
> with user networking (slirp) should now start with the helper process.
>
> thanks
>
> Marc-André Lureau (8):
>   qemu: remove dbus-vmstate code
>   qemu-conf: add configurable dbus-daemon location
>   qemu-conf: add dbusStateDir
>   qemu: add a DBus daemon helper unit
>   domain: save/restore the state of dbus-daemon running
>   qemu: prepare and stop the dbus daemon
>   qemu: add dbus-vmstate helper migration support
>   qemu-slirp: register helper for migration

Can I get some feedback/review on the series?

Fwiw, in the past month, we have seen a new implementation emerge
(https://github.com/majek/slirpnetstack) and this made me reconsider a
number of CLI/capabilities things from the spec. I moved the spec on a
wiki for now: 
https://gitlab.freedesktop.org/slirp/libslirp/-/wikis/Slirp-Helper.
We are also discussing with podman developpers about it.

Given that this is not frozen, and no helper was released so far, I
understand that libvirt may want to back off a little. Yet, your
feedback could also help shape/define the helper behaviour!

So please, take a look :)
thanks

>
>  m4/virt-driver-qemu.m4 |   6 +
>  src/qemu/Makefile.inc.am   |   6 +-
>  src/qemu/libvirtd_qemu.aug |   1 +
>  src/qemu/qemu.conf |   3 +
>  src/qemu/qemu_alias.c  |  17 +-
>  src/qemu/qemu_alias.h  |   3 +-
>  src/qemu/qemu_command.c|  65 +++
>  src/qemu/qemu_command.h|   6 +-
>  src/qemu/qemu_conf.c   |   9 +
>  src/qemu/qemu_conf.h   |   2 +
>  src/qemu/qemu_dbus.c   | 283 +
>  src/qemu/qemu_dbus.h   |  30 +--
>  src/qemu/qemu_domain.c |  30 +--
>  src/qemu/qemu_domain.h |   9 +-
>  src/qemu/qemu_extdevice.c  |   4 +-
>  src/qemu/qemu_hotplug.c| 165 +
>  src/qemu/qemu_hotplug.h|  17 +-
>  src/qemu/qemu_migration.c  |  57 +-
>  src/qemu/qemu_monitor.c|  21 +++
>  src/qemu/qemu_monitor.h|   3 +
>  src/qemu/qemu_monitor_json.c   |  15 ++
>  src/qemu/qemu_monitor_json.h   |   5 +
>  src/qemu/qemu_process.c|   6 +
>  src/qemu/qemu_slirp.c  | 126 ++---
>  src/qemu/qemu_slirp.h  |   4 +-
>  src/qemu/test_libvirtd_qemu.aug.in |   1 +
>  tests/Makefile.am  |   1 +
>  27 files changed, 564 insertions(+), 331 deletions(-)
>
> --
> 2.25.0.rc2.1.g09a9a1a997
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Marc-André Lureau

Re: [PATCH 0/5] Add support for SPAPR vTPM for pSeries VM

[Marc-André Lureau]

On Fri, Jan 31, 2020 at 10:17 PM Stefan Berger  wrote:
>
> QEMU 5.0 will have SPAPR vTPM support. This series of patches
> adds support for the XML and command line creation of the
> SPAPR vTPM for pSeries VMs along with test cases.
>
> Regards,
>Stefan
>
> Stefan Berger (5):
>   conf: Add support for tpm-spapr to domain XML
>   qemu: Extend QEMU capabilities with 'tpm-spapr'
>   qemu: Extend QEMU with tpm-spapr support
>   tests: Extend ppc64 capabilities data with TPM related XML and
> responses
>   tests: Add test for domain XML with tpm-spapr TPM device model
>
>  docs/formatdomain.html.in | 4 +-
>  docs/schemas/domaincommon.rng | 4 +
>  src/conf/domain_conf.c|24 +-
>  src/conf/domain_conf.h| 1 +
>  src/qemu/qemu_capabilities.c  | 6 +
>  src/qemu/qemu_capabilities.h  | 1 +
>  src/qemu/qemu_command.c   |15 +-
>  src/qemu/qemu_domain.c| 8 +-
>  src/qemu/qemu_domain_address.c|10 +
>  tests/domaincapsdata/qemu_5.0.0.ppc64.xml |   115 +
>  .../caps_5.0.0.ppc64.replies  | 24695 
>  .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml |  1128 +
>  .../tpm-emulator-spapr.ppc64-latest.args  |45 +
>  tests/qemuxml2argvdata/tpm-emulator-spapr.xml |60 +
>  tests/qemuxml2argvtest.c  | 4 +
>  15 files changed, 26105 insertions(+), 15 deletions(-)
>  create mode 100644 tests/domaincapsdata/qemu_5.0.0.ppc64.xml
>  create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.replies
>  create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
>  create mode 100644 
> tests/qemuxml2argvdata/tpm-emulator-spapr.ppc64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/tpm-emulator-spapr.xml
>

Series:
Reviewed-by: Marc-André Lureau 


> --
> 2.17.1
>

Re: [libvirt] [PATCH v5 02/20] qemu-interop: ignore non-readable directories

[Marc-André Lureau]

Hi

On Tue, Sep 24, 2019 at 2:08 PM Ján Tomko  wrote:
>
> On Tue, Sep 24, 2019 at 10:12:19AM +0400, Marc-André Lureau wrote:
> >Hi
> >
> >On Mon, Sep 23, 2019 at 4:35 PM Ján Tomko  wrote:
> >>
> >> On Mon, Sep 23, 2019 at 02:44:25PM +0400, marcandre.lur...@redhat.com 
> >> wrote:
> >> >From: Marc-André Lureau 
> >> >
> >> >Whether a directory is missing or is not readable doesn't make much
> >> >difference when populating the available configs.
> >> >
> >> >This removes errors when firmare or vhost-user config is looked up
> >> >from a user session libvirt if /etc/libvirt is not readable for ex.
> >> >
> >> >Signed-off-by: Marc-André Lureau 
> >> >---
> >> > src/qemu/qemu_interop_config.c | 8 +++-
> >> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >> >
> >> >diff --git a/src/qemu/qemu_interop_config.c 
> >> >b/src/qemu/qemu_interop_config.c
> >> >index 1f39d4b576..f3c5d2e083 100644
> >> >--- a/src/qemu/qemu_interop_config.c
> >> >+++ b/src/qemu/qemu_interop_config.c
> >> >@@ -41,8 +41,14 @@ qemuBuildFileList(virHashTablePtr files, const char 
> >> >*dir)
> >> > int rc;
> >> > int ret = -1;
> >> >
> >> >-if ((rc = virDirOpenIfExists(, dir)) < 0)
> >> >+if ((rc = virDirOpenIfExists(, dir)) < 0) {
> >> >+/* silently ignore unreadable directories */
> >>
> >> This will not be silent - virDirOpenIfExists already logged an error.
> >
> >Right, let's drop the comment.
> >
> >>
> >> You can call virFileExists upfront - which is just a wrapper to access
> >> and then take virDirOpenIfExists errors seriously - if someone changes
> >> the permissions in the meantime, they deserve the error.
> >
> >That won't work the desired way, since virFileExists() is true even
> >when you don't have permissions to read it.
> >
> >>
> >> >+if (virLastErrorIsSystemErrno(EACCES)) {
> >> >+virResetLastError();
> >> >+return 0;
> >> >+}
> >> > return -1;
> >> >+}
> >> >
> >>
> >> With that fixed:
> >> Reviewed-by: Ján Tomko 
> >
> >I see several ways forward, if any of the directory doesn't have
> >readable permissions :
> >
> >1. keep behaviour before this patch: fail entirely. This is
> >unnecessarily strict imho
> >2. use this patch (remove the comment): log an error, but browse other
> >directories
> >3. change the code further so that no error is logged
> >
> >To me, 2 is a good compromise.
> >
> >Does your r-b tag holds with the comment removed only?
> >
>
> Logging errors that are not treated as such pollutes logs and misleads
> users.
>

It's treated as an error: it logs an error, but it's not fatal.

> I assume the only possible path here is QEMU_ETC_LOCATION - the user
> should have access to $HOME and preventing access to /usr/share does
> not sound like a reasonable system.
>
> What would be the benefits of making /etc/qemu private? If it's
> a misconfiguration, we don't have to be lenient here and can go with #1

It could be a misconfiguration or an administrator policy. In both
cases, it's not a good idea to prevent the user from starting the VM
with the user configs.

>
> Otherwise, making
>   virFileAccessibleAs(etcLocation, R_OK | X_OK, geteuid(), getegid())
> a condition for
> if (qemuBuildFileList(files, etcLocation) < 0)
> return -1;
> seems to be the least effort to silence unaccessible /etc/qemu while still
> erroring out on the required cases.

Sounds okay to me, but the user would have no clear clue that
something unusual happened (that system config are not readable).

>
> Jano
>
>
> >thanks
> >
> >--
> >libvir-list mailing list
> >libvir-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v5 02/20] qemu-interop: ignore non-readable directories

[Marc-André Lureau]

Hi

On Mon, Sep 23, 2019 at 4:35 PM Ján Tomko  wrote:
>
> On Mon, Sep 23, 2019 at 02:44:25PM +0400, marcandre.lur...@redhat.com wrote:
> >From: Marc-André Lureau 
> >
> >Whether a directory is missing or is not readable doesn't make much
> >difference when populating the available configs.
> >
> >This removes errors when firmare or vhost-user config is looked up
> >from a user session libvirt if /etc/libvirt is not readable for ex.
> >
> >Signed-off-by: Marc-André Lureau 
> >---
> > src/qemu/qemu_interop_config.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> >diff --git a/src/qemu/qemu_interop_config.c b/src/qemu/qemu_interop_config.c
> >index 1f39d4b576..f3c5d2e083 100644
> >--- a/src/qemu/qemu_interop_config.c
> >+++ b/src/qemu/qemu_interop_config.c
> >@@ -41,8 +41,14 @@ qemuBuildFileList(virHashTablePtr files, const char *dir)
> > int rc;
> > int ret = -1;
> >
> >-if ((rc = virDirOpenIfExists(, dir)) < 0)
> >+if ((rc = virDirOpenIfExists(, dir)) < 0) {
> >+/* silently ignore unreadable directories */
>
> This will not be silent - virDirOpenIfExists already logged an error.

Right, let's drop the comment.

>
> You can call virFileExists upfront - which is just a wrapper to access
> and then take virDirOpenIfExists errors seriously - if someone changes
> the permissions in the meantime, they deserve the error.

That won't work the desired way, since virFileExists() is true even
when you don't have permissions to read it.

>
> >+if (virLastErrorIsSystemErrno(EACCES)) {
> >+virResetLastError();
> >+return 0;
> >+}
> > return -1;
> >+}
> >
>
> With that fixed:
> Reviewed-by: Ján Tomko 

I see several ways forward, if any of the directory doesn't have
readable permissions :

1. keep behaviour before this patch: fail entirely. This is
unnecessarily strict imho
2. use this patch (remove the comment): log an error, but browse other
directories
3. change the code further so that no error is logged

To me, 2 is a good compromise.

Does your r-b tag holds with the comment removed only?

thanks

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 14/20] qemu: add vhost-user-gpu helper unit

[Marc-André Lureau]

Hi

On Sat, Sep 21, 2019 at 1:05 AM Cole Robinson  wrote:
>
> On 9/13/19 8:50 AM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Similar to the qemu_tpm.c, add a unit with a few functions to
> > start/stop and setup the cgroup of the external vhost-user-gpu
> > process. See function documentation.
> >
> > The vhost-user connection fd is set on qemuDomainVideoPrivate struct.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   src/qemu/Makefile.inc.am   |   2 +
> >   src/qemu/qemu_domain.c |   5 +-
> >   src/qemu/qemu_domain.h |   2 +-
> >   src/qemu/qemu_vhost_user_gpu.c | 276 +
> >   src/qemu/qemu_vhost_user_gpu.h |  49 ++
> >   5 files changed, 332 insertions(+), 2 deletions(-)
> >   create mode 100644 src/qemu/qemu_vhost_user_gpu.c
> >   create mode 100644 src/qemu/qemu_vhost_user_gpu.h
> >
> > diff --git a/src/qemu/Makefile.inc.am b/src/qemu/Makefile.inc.am
> > index 449550e64b..8040bf9366 100644
> > --- a/src/qemu/Makefile.inc.am
> > +++ b/src/qemu/Makefile.inc.am
> > @@ -66,6 +66,8 @@ QEMU_DRIVER_SOURCES = \
> >   qemu/qemu_tpm.h \
> >   qemu/qemu_vhost_user.c \
> >   qemu/qemu_vhost_user.h \
> > + qemu/qemu_vhost_user_gpu.c \
> > + qemu/qemu_vhost_user_gpu.h \
> >   $(NULL)
> >
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index 9437694940..ab923aa917 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -1341,8 +1341,11 @@ qemuDomainVideoPrivateNew(void)
> >
> >
> >   static void
> > -qemuDomainVideoPrivateDispose(void *obj ATTRIBUTE_UNUSED)
> > +qemuDomainVideoPrivateDispose(void *obj)
> >   {
> > +qemuDomainVideoPrivatePtr priv = obj;
> > +
> > +VIR_FORCE_CLOSE(priv->vhost_user_fd);
> >   }
> >
> >
> > diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
> > index 89bd77b3c0..8afb4993d3 100644
> > --- a/src/qemu/qemu_domain.h
> > +++ b/src/qemu/qemu_domain.h
> > @@ -509,7 +509,7 @@ typedef qemuDomainVideoPrivate 
> > *qemuDomainVideoPrivatePtr;
> >   struct _qemuDomainVideoPrivate {
> >   virObject parent;
> >
> > -bool tmp_to_remove;
> > +int vhost_user_fd;
> >   };
> >
> >
> > diff --git a/src/qemu/qemu_vhost_user_gpu.c b/src/qemu/qemu_vhost_user_gpu.c
> > new file mode 100644
> > index 00..b259b58434
> > --- /dev/null
> > +++ b/src/qemu/qemu_vhost_user_gpu.c
> > @@ -0,0 +1,276 @@
> > +/*
> > + * qemu_vhost_user_gpu.c: QEMU vhost-user GPU support
> > + *
> > + * Copyright (C) 2019 Red Hat, Inc.
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library.  If not, see
> > + * <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include 
> > +
> > +#include "qemu_vhost_user_gpu.h"
> > +#include "qemu_vhost_user.h"
> > +#include "qemu_extdevice.h"
> > +
> > +#include "conf/domain_conf.h"
> > +#include "configmake.h"
> > +#include "vircommand.h"
> > +#include "viralloc.h"
> > +#include "virlog.h"
> > +#include "virutil.h"
> > +#include "virfile.h"
> > +#include "virstring.h"
> > +#include "virtime.h"
> > +#include "virpidfile.h"
> > +
> > +#define VIR_FROM_THIS VIR_FROM_NONE
> > +
> > +VIR_LOG_INIT("qemu.vhost_user_gpu");
> > +
> > +
> > +static char *
> > +qemuVhostUserGPUCreatePidFilename(const char *stateDir,
> > +  const char *shortName,
> > +  const char *alias)
> > +{
> > +VIR_AUTOFREE(char *) devicename = NULL;
> > +
> > +if (virAsp

Re: [libvirt] [PATCH 4/4] qemu_capabilities: Temporarily disable dbus-vmstate capability

[Marc-André Lureau]

Hi

On Mon, Sep 9, 2019 at 2:49 PM Ján Tomko  wrote:
>
> On Mon, Sep 09, 2019 at 11:23:59AM +0200, Michal Privoznik wrote:
> >On 9/6/19 5:55 PM, Ján Tomko wrote:
> >>[cc-ing Marc-André]
> >>
> >>On Fri, Sep 06, 2019 at 04:25:19PM +0200, Michal Privoznik wrote:
> >>>The qemu side is not merged in yet, so there is a chance that the
> >>>interface will change. Don't detect the capability just yet then.
> >>>
> >>>Signed-off-by: Michal Privoznik 
> >>>---
> >>>src/qemu/qemu_capabilities.c | 1 -
> >>>1 file changed, 1 deletion(-)
> >>>
> >>>diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> >>>index 136999ad0d..7be026ae12 100644
> >>>--- a/src/qemu/qemu_capabilities.c
> >>>+++ b/src/qemu/qemu_capabilities.c
> >>>@@ -1129,7 +1129,6 @@ struct virQEMUCapsStringFlags
> >>>virQEMUCapsObjectTypes[] = {
> >>>{ "virtio-serial-pci-non-transitional",
> >>>QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
> >>>{ "max-x86_64-cpu", QEMU_CAPS_X86_MAX_CPU },
> >>>{ "bochs-display", QEMU_CAPS_DEVICE_BOCHS_DISPLAY },
> >>>-{ "dbus-vmstate", QEMU_CAPS_DBUS_VMSTATE },
> >>>};
> >>>
> >>>static struct virQEMUCapsStringFlags
> >>>virQEMUCapsDevicePropsVirtioBalloon[] = {
> >>
> >>If
> >>1) dbus-vmstate is required for migration of a domain using a
> >>slirp-helper and
> >>2) we enable this automatically for existing XML configs with
> >>   if
> >>  a) QEMU has QEMU_CAPS_NET_SOCKET_DGRAM
> >>  b) the slirp-helper process is installed on the system
> >>then we've effectively made their machines unmigratable
> >>
> >>So if we want to enable it automatically, we should add:
> >>c) QEMU has QEMU_CAPS_DBUS_VMSTATE
> >>regardless of whether dbus-vmstate gets merged into QEMU until libvirt's
> >>next release
> >
> >So are you saying that we should just temporarily revert
> >QEMU_CAPS_NET_SOCKET_DGRAM detection instead and leave
> >QEMU_CAPS_DBUS_VMSTATE be?
>
> Give that there was a QEMU release which has one but not the other,
> I'd say permanently revert QEMU_CAPS_NET_SOCKET_DGRAM - even if
> dbus-vmstate gets merged later, there has been a QEMU release for which
> we assume one capability and not the other - so libvirt would be
> starting unmigratable machines.
>
> As for QEMU_CAPS_DBUS_VMSTATE, we can either revert it temporarily now
> or before the libvirt freeze if dbus-vmstate does not get merged by
> then.

I agree that as long as qemu doesn't have dbus-vmstate, it is better
to revert dbus-vmstate support, and disable net-socket-dgram.

>
> Jano
>
> >
> >Michal
> >
> >--
> >libvir-list mailing list
> >libvir-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Revert "dbus: correctly build reply message"

[Marc-André Lureau]

Hi

On Fri, Sep 6, 2019 at 7:37 PM Michal Privoznik  wrote:
>
> This reverts commit 39dded7bb61444bb608fadd3f82f6fe93d08fd0e.
>
> This commit broke virpolkittest on Ubuntu 18 which has an old
> dbus (v1.12.2). Any other distro with the recent one works
> (v1.12.16) which hints its a bug in dbus somewhere. Revert the
> commit to stop tickling it.
>
> Signed-off-by: Michal Privoznik 

This patch is no longer necessary for dbus-vmstate in this series. I
found this "bug" when implementing an alternative solution. So
reverting it is fine by me.

However, it may be revealing a transient bug in
virDBusMessageIterDecode() rather than libdbus. It would be worth to
have VIR_DEBUG() output from the failing test.

For now:
Reviewed-by: Marc-André Lureau 


> ---
>  src/util/virdbus.c  | 18 ++
>  src/util/virdbus.h  |  6 ++
>  tests/virfirewalltest.c |  9 +++--
>  tests/virpolkittest.c   |  3 +--
>  4 files changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/src/util/virdbus.c b/src/util/virdbus.c
> index 64513eef14..b0ac8d7055 100644
> --- a/src/util/virdbus.c
> +++ b/src/util/virdbus.c
> @@ -1456,7 +1456,6 @@ int virDBusCreateMethod(DBusMessage **call,
>
>  /**
>   * virDBusCreateReplyV:
> - * @msg: the message to reply to
>   * @reply: pointer to be filled with a method reply message
>   * @types: type signature for following method arguments
>   * @args: method arguments
> @@ -1469,14 +1468,13 @@ int virDBusCreateMethod(DBusMessage **call,
>   * as variadic args. See virDBusCreateMethodV for a
>   * description of this parameter.
>   */
> -int virDBusCreateReplyV(DBusMessage *msg,
> -DBusMessage **reply,
> +int virDBusCreateReplyV(DBusMessage **reply,
>  const char *types,
>  va_list args)
>  {
>  int ret = -1;
>
> -if (!(*reply = dbus_message_new_method_return(msg))) {
> +if (!(*reply = dbus_message_new(DBUS_MESSAGE_TYPE_METHOD_RETURN))) {
>  virReportOOMError();
>  goto cleanup;
>  }
> @@ -1495,7 +1493,6 @@ int virDBusCreateReplyV(DBusMessage *msg,
>
>  /**
>   * virDBusCreateReply:
> - * @msg: the message to reply to
>   * @reply: pointer to be filled with a method reply message
>   * @types: type signature for following method arguments
>   * @...: method arguments
> @@ -1503,15 +1500,14 @@ int virDBusCreateReplyV(DBusMessage *msg,
>   * See virDBusCreateReplyV for a description of the
>   * behaviour of this method.
>   */
> -int virDBusCreateReply(DBusMessage *msg,
> -   DBusMessage **reply,
> +int virDBusCreateReply(DBusMessage **reply,
> const char *types, ...)
>  {
>  va_list args;
>  int ret;
>
>  va_start(args, types);
> -ret = virDBusCreateReplyV(msg, reply, types, args);
> +ret = virDBusCreateReplyV(reply, types, args);
>  va_end(args);
>
>  return ret;
> @@ -1815,8 +1811,7 @@ int virDBusCreateMethodV(DBusMessage **call 
> ATTRIBUTE_UNUSED,
>  return -1;
>  }
>
> -int virDBusCreateReplyV(DBusMessage *msg ATTRIBUTE_UNUSED,
> -DBusMessage **reply ATTRIBUTE_UNUSED,
> +int virDBusCreateReplyV(DBusMessage **reply ATTRIBUTE_UNUSED,
>  const char *types ATTRIBUTE_UNUSED,
>  va_list args ATTRIBUTE_UNUSED)
>  {
> @@ -1825,8 +1820,7 @@ int virDBusCreateReplyV(DBusMessage *msg 
> ATTRIBUTE_UNUSED,
>  return -1;
>  }
>
> -int virDBusCreateReply(DBusMessage *msg ATTRIBUTE_UNUSED,
> -   DBusMessage **reply ATTRIBUTE_UNUSED,
> +int virDBusCreateReply(DBusMessage **reply ATTRIBUTE_UNUSED,
> const char *types ATTRIBUTE_UNUSED, ...)
>  {
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> diff --git a/src/util/virdbus.h b/src/util/virdbus.h
> index 0303e91045..083c074d59 100644
> --- a/src/util/virdbus.h
> +++ b/src/util/virdbus.h
> @@ -52,11 +52,9 @@ int virDBusCreateMethodV(DBusMessage **call,
>   const char *member,
>   const char *types,
>   va_list args);
> -int virDBusCreateReply(DBusMessage *msg,
> -   DBusMessage **reply,
> +int virDBusCreateReply(DBusMessage **reply,
> const char *types, ...);
> -int virDBusCreateReplyV(DBusMessage *msg,
> -DBusMessage **reply,
> +int virDBusCreateReplyV(DBusMessage **reply,
>  const char *types,
>  va_list args);
>
> diff --git a/tests/virfirewalltest.c b/tests/virfirewalltest.c
> index e5e

Re: [libvirt] [PATCH v2 03/16] domain: add rendernode attribute on

[Marc-André Lureau]

Hi

On Fri, Aug 23, 2019 at 9:05 PM Cole Robinson  wrote:
>
> On 8/23/19 12:21 PM, Cole Robinson wrote:
> > From: Marc-André Lureau 
> >
> > vhost-user-gpu helper may accept --render-node option to specify on
> > which GPU should the renderning be done.
> >
>
> What does it do if the user doesn't pass one? Pick one itself, or just
> not use one somehow?

This is left unspecified. So it may probe one itself and use it, or
fallback to full-software.

>
> If it picks one, then we may need to treat this like we treat other
> rendernode instances and autoallocate one if the user doesn't specify,
> otherwise we won't be able to add the path to the cgroup for example, or
> selinux label it if necessary. I'm not sure if that actually applies in
> this case, but it's worth considering.
>

I think we may want to auto-allocate a drm node if the helper accepts
the argument, as it is almost always what you'd want. But then we lose
the ability to *not* specify it. I am fine with that.


> > (by comparison  rendernode is the target/display rendering)
> >
> > Signed-off-by: Marc-André Lureau 
> > Signed-off-by: Cole Robinson 
>
> Also I see now that I accidentally signed off all these patches, that
> was not intentional. Please strip those from v3
>
> > ---
> >  docs/formatdomain.html.in |  5 +
> >  docs/schemas/domaincommon.rng |  5 +
> >  src/conf/domain_conf.c| 18 +-
> >  src/conf/domain_conf.h|  1 +
> >  4 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> > index ec650fbe17..5a4807d937 100644
> > --- a/docs/formatdomain.html.in
> > +++ b/docs/formatdomain.html.in
> > @@ -7059,6 +7059,11 @@ qemu-kvm -net nic,model=? /dev/null
> >  Enable 3D acceleration (for vbox driver
> >  since 0.7.1, qemu driver
> >  since 1.3.0)
> > +
> > +rendernode
> > +Absolute path to a host's DRI device to be used for
> > +rendering (for vhost-user driver only,  > +class="since">since 5.5.0)
> >  
> >
> >
> > diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> > index bac566855d..6e91fe6cef 100644
> > --- a/docs/schemas/domaincommon.rng
> > +++ b/docs/schemas/domaincommon.rng
> > @@ -3644,6 +3644,11 @@
> >
> >  
> >
> > +  
> > +
> > +  
> > +
> > +  
> >  
> >
> >  
> > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> > index f51575d57d..2cc055491d 100644
> > --- a/src/conf/domain_conf.c
> > +++ b/src/conf/domain_conf.c
> > @@ -2832,6 +2832,8 @@ virDomainVideoDefClear(virDomainVideoDefPtr def)
> >
> >  virDomainDeviceInfoClear(>info);
> >
> > +if (def->accel)
> > +VIR_FREE(def->accel->rendernode);
> >  VIR_FREE(def->accel);
> >  VIR_FREE(def->virtio);
> >  VIR_FREE(def->driver);
> > @@ -15270,6 +15272,7 @@ virDomainVideoAccelDefParseXML(xmlNodePtr node)
> >  int val;
> >  VIR_AUTOFREE(char *) accel2d = NULL;
> >  VIR_AUTOFREE(char *) accel3d = NULL;
> > +VIR_AUTOFREE(char *) rendernode = NULL;
> >
> >  cur = node->children;
> >  while (cur != NULL) {
> > @@ -15278,12 +15281,13 @@ virDomainVideoAccelDefParseXML(xmlNodePtr node)
> >  virXMLNodeNameEqual(cur, "acceleration")) {
> >  accel3d = virXMLPropString(cur, "accel3d");
> >  accel2d = virXMLPropString(cur, "accel2d");
> > +rendernode = virXMLPropString(cur, "rendernode");
> >  }
> >  }
> >  cur = cur->next;
> >  }
> >
> > -if (!accel3d && !accel2d)
> > +if (!accel3d && !accel2d && !rendernode)
> >  return NULL;
> >
> >  if (VIR_ALLOC(def) < 0)
> > @@ -15307,6 +15311,9 @@ virDomainVideoAccelDefParseXML(xmlNodePtr node)
> >  def->accel2d = val;
> >  }
> >
> > +if (VIR_STRDUP(def->rendernode, rendernode) < 0)
> > +goto cleanup;
> > +
>
> Huh, this function has no error reporting? A bogus accel2d/accel3d value
> will raise an error but it never triggers the error path in the calling
> function. Not your fault of cour

Re: [libvirt] [PATCH v2 09/16] qemu: add vhost-user helpers

[Marc-André Lureau]

Hi

On Tue, Aug 27, 2019 at 12:29 PM Ján Tomko  wrote:
>
> On Fri, Aug 23, 2019 at 12:21:53PM -0400, Cole Robinson wrote:
> >From: Marc-André Lureau 
> >
> >Add qemuVhostUserFetchConfigs() to discover vhost-user helpers.
> >
> >qemuVhostUserFillDomainGPU() will find the first matching GPU helper
> >with the required capabilities and set the associated
> >vhost_user_binary.
> >
>
> Looks good, but it seems like something we might want to start caching
> over time, especially if more than one helper per domain will be needed.
>
> >Signed-off-by: Marc-André Lureau 
> >Signed-off-by: Cole Robinson 
> >---
> > src/conf/device_conf.c|   1 +
> > src/conf/device_conf.h|   1 +
> > src/qemu/Makefile.inc.am  |   2 +
> > src/qemu/qemu_vhost_user.c| 394 ++
> > src/qemu/qemu_vhost_user.h|  48 +++
> > tests/Makefile.am |   9 +
> > .../etc/qemu/vhost-user/40-gpu.json   |   1 +
> > .../etc/qemu/vhost-user/50-gpu.json   |   0
> > .../qemu/vhost-user/test-vhost-user-gpu   |  11 +
> > .../usr/share/qemu/vhost-user/30-gpu.json |   1 +
> > .../usr/share/qemu/vhost-user/50-gpu.json |   8 +
> > .../usr/share/qemu/vhost-user/60-gpu.json |   1 +
> > tests/qemuvhostusertest.c | 132 ++
> > 13 files changed, 609 insertions(+)
> > create mode 100644 src/qemu/qemu_vhost_user.c
> > create mode 100644 src/qemu/qemu_vhost_user.h
> > create mode 12 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json
> > create mode 100644 tests/qemuvhostuserdata/etc/qemu/vhost-user/50-gpu.json
> > create mode 100755 
> > tests/qemuvhostuserdata/usr/libexec/qemu/vhost-user/test-vhost-user-gpu
> > create mode 12 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/30-gpu.json
> > create mode 100644 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/50-gpu.json
> > create mode 12 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/60-gpu.json
> > create mode 100644 tests/qemuvhostusertest.c
> >
> >diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> >index 4c57f0995f..2f7077ddc4 100644
> >--- a/src/conf/device_conf.c
> >+++ b/src/conf/device_conf.c
> >@@ -96,6 +96,7 @@ virDomainDeviceInfoClear(virDomainDeviceInfoPtr info)
> > VIR_FREE(info->loadparm);
> > info->isolationGroup = 0;
> > info->isolationGroupLocked = false;
> >+VIR_FREE(info->vhost_user_binary);
> > }
> >
> > void
> >diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
> >index d0854925e3..0b0c525ad8 100644
> >--- a/src/conf/device_conf.h
> >+++ b/src/conf/device_conf.h
> >@@ -179,6 +179,7 @@ struct _virDomainDeviceInfo {
> >  * cases we might want to prevent that from happening by
> >  * locking the isolation group */
> > bool isolationGroupLocked;
> >+char *vhost_user_binary;
> > };
> >
>
> Not sure about the placement in DeviceInfo, looks more fit for 'driver'
> to me.
>

That wouldn't follow firmware code, but other than that, driver
doesn't really fit either since it's a per-domain/device value.


-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 09/16] qemu: add vhost-user helpers

[Marc-André Lureau]

Hi

On Tue, Aug 27, 2019 at 12:30 AM Cole Robinson  wrote:
>
> On 8/23/19 12:21 PM, Cole Robinson wrote:
> > From: Marc-André Lureau 
> >
> > Add qemuVhostUserFetchConfigs() to discover vhost-user helpers.
> >
> > qemuVhostUserFillDomainGPU() will find the first matching GPU helper
> > with the required capabilities and set the associated
> > vhost_user_binary.
> >
> > Signed-off-by: Marc-André Lureau 
> > Signed-off-by: Cole Robinson 
> > ---
> >  src/conf/device_conf.c|   1 +
> >  src/conf/device_conf.h|   1 +
> >  src/qemu/Makefile.inc.am  |   2 +
> >  src/qemu/qemu_vhost_user.c| 394 ++
> >  src/qemu/qemu_vhost_user.h|  48 +++
> >  tests/Makefile.am |   9 +
> >  .../etc/qemu/vhost-user/40-gpu.json   |   1 +
> >  .../etc/qemu/vhost-user/50-gpu.json   |   0
> >  .../qemu/vhost-user/test-vhost-user-gpu   |  11 +
> >  .../usr/share/qemu/vhost-user/30-gpu.json |   1 +
> >  .../usr/share/qemu/vhost-user/50-gpu.json |   8 +
> >  .../usr/share/qemu/vhost-user/60-gpu.json |   1 +
> >  tests/qemuvhostusertest.c | 132 ++
> >  13 files changed, 609 insertions(+)
> >  create mode 100644 src/qemu/qemu_vhost_user.c
> >  create mode 100644 src/qemu/qemu_vhost_user.h
> >  create mode 12 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json
> >  create mode 100644 tests/qemuvhostuserdata/etc/qemu/vhost-user/50-gpu.json
> >  create mode 100755 
> > tests/qemuvhostuserdata/usr/libexec/qemu/vhost-user/test-vhost-user-gpu
> >  create mode 12 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/30-gpu.json
> >  create mode 100644 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/50-gpu.json
> >  create mode 12 
> > tests/qemuvhostuserdata/usr/share/qemu/vhost-user/60-gpu.json
> >  create mode 100644 tests/qemuvhostusertest.c
> >
> > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > index 4c57f0995f..2f7077ddc4 100644
> > --- a/src/conf/device_conf.c
> > +++ b/src/conf/device_conf.c
> > @@ -96,6 +96,7 @@ virDomainDeviceInfoClear(virDomainDeviceInfoPtr info)
> >  VIR_FREE(info->loadparm);
> >  info->isolationGroup = 0;
> >  info->isolationGroupLocked = false;
> > +VIR_FREE(info->vhost_user_binary);
> >  }
> >
> >  void
> > diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
> > index d0854925e3..0b0c525ad8 100644
> > --- a/src/conf/device_conf.h
> > +++ b/src/conf/device_conf.h
> > @@ -179,6 +179,7 @@ struct _virDomainDeviceInfo {
> >   * cases we might want to prevent that from happening by
> >   * locking the isolation group */
> >  bool isolationGroupLocked;
> > +char *vhost_user_binary;
> >  };
> >
> >  void virDomainDeviceInfoClear(virDomainDeviceInfoPtr info);
> > diff --git a/src/qemu/Makefile.inc.am b/src/qemu/Makefile.inc.am
> > index f7a0fa4a84..18a9220d01 100644
> > --- a/src/qemu/Makefile.inc.am
> > +++ b/src/qemu/Makefile.inc.am
> > @@ -60,6 +60,8 @@ QEMU_DRIVER_SOURCES = \
> >   qemu/qemu_qapi.h \
> >   qemu/qemu_tpm.c \
> >   qemu/qemu_tpm.h \
> > + qemu/qemu_vhost_user.c \
> > + qemu/qemu_vhost_user.h \
> >   $(NULL)
> >
> >
> > diff --git a/src/qemu/qemu_vhost_user.c b/src/qemu/qemu_vhost_user.c
> > new file mode 100644
> > index 00..7a97052ab9
> > --- /dev/null
> > +++ b/src/qemu/qemu_vhost_user.c
> > @@ -0,0 +1,394 @@
> > +/*
> > + * qemu_vhost_user.c: QEMU vhost-user
> > + *
> > + * Copyright (C) 2019 Red Hat, Inc.
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library.  If not, see
> > + * <http://www.gnu.org/licenses/>.
> > + */
> > +

Re: [libvirt] [PATCH v2 14/16] qemu: build vhost-user GPU devices

[Marc-André Lureau]

Hi

On Tue, Aug 27, 2019 at 1:17 PM Ján Tomko  wrote:
>
> On Fri, Aug 23, 2019 at 12:21:58PM -0400, Cole Robinson wrote:
> >From: Marc-André Lureau 
> >
> >For each vhost-user GPUs,
> >- build a socket chardev, and pass the vhost-user socket to it
> >- build a vhost-user video device and associate it with the chardev
> >
> >Signed-off-by: Marc-André Lureau 
> >Signed-off-by: Cole Robinson 
> >---
> > src/qemu/qemu_command.c | 46 +++--
> > 1 file changed, 44 insertions(+), 2 deletions(-)
> >
> >diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> >index 8bef103f68..0e1d9510e5 100644
> >--- a/src/qemu/qemu_command.c
> >+++ b/src/qemu/qemu_command.c
> >@@ -4672,8 +4672,15 @@ qemuBuildDeviceVideoStr(const virDomainDef *def,
> > goto error;
> > }
> >
> >-if (STREQ(model, "virtio-gpu")) {
> >-if (qemuBuildVirtioDevStr(, "virtio-gpu", qemuCaps,
>
> Eww, why do we do a string comparison here when we store the model as an
> enum?

Yup, pre-existing. I suppose that can be fixed.

>
> >+if (video->vhostuser) {
> >+if (STREQ(model, "virtio-vga"))
> >+model = "vhost-user-vga";
> >+if (STREQ(model, "virtio-gpu"))
> >+model = "vhost-user-gpu";
> >+}
>
> Not sure why we need to reassign model here instead of getting it right
> the first time.
>
> >+
>
> How different is the vhost-user-gpu device from virtio-gpu,
> don't we new a new VIDEO_TYPE_VHOST_USER instead?

>From guest PoV, it's actually the same device. So we shouldn't
introduce a new virDomainVideoType, right? But we need a mapping to
-device, it has to be in libvirt qemu driver.


>
>
> if (video->type == VIRTIO && !primary) for the condition below:
>
> >+if (STREQ(model, "virtio-gpu") || STREQ(model, "vhost-user-gpu")) {
> >+if (qemuBuildVirtioDevStr(, model, qemuCaps,
> >   VIR_DOMAIN_DEVICE_VIDEO, video) < 0) {
> > goto error;
> > }
>
> Jano
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 02/16] domain: add "vhostuser" attribute to virtio video model

[Marc-André Lureau]

Hi

On Tue, Aug 27, 2019 at 11:19 AM Ján Tomko  wrote:
>
> On Fri, Aug 23, 2019 at 12:51:56PM -0400, Cole Robinson wrote:
> >On 8/23/19 12:21 PM, Cole Robinson wrote:
> >> From: Marc-André Lureau 
> >>
> >> Accept a new attribute to specify usage of helper process, ex:
> >>
> >>   
> >> 
> >>   
> >>
> >
> >For other devices, we have
> >
> >
> >
> >
> >
> >Which is an attempt to make this more generic.
>
> >IMO using vhostuser='yes'
>
> missing verb?
>
> >and is the simplest match to qemu terminology but maybe other people
> >have stronger opinions.
>
> Yes.
>
> This does not belong in the model - it's a backend thing.
>
>  sounds best to me (and similarly to
> what commit 175077fd707db6ad87d6e2a079e82bc290ac2421 did,
> we can also expose )

Shouldn't it be ?

('vhost' would be for a kernel backend)

>
> Jano
>
> >
> >> Signed-off-by: Marc-André Lureau 
> >> Signed-off-by: Cole Robinson 
> >> ---
> >>  docs/formatdomain.html.in |  6 ++
> >>  docs/schemas/domaincommon.rng | 11 ++-
> >>  src/conf/domain_conf.c    | 14 ++
> >>  src/conf/domain_conf.h|  1 +
> >>  4 files changed, 31 insertions(+), 1 deletion(-)
> >>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Revert "tpm: Check TPM XML device configuration changes after edit"

[Marc-André Lureau]

ObjPtr vm;
> -int ret;
> -
> -vm = virDomainObjListFindByUUID(driver->domains, def->uuid);
> -if (!vm)
> -return 0;
> -
> -if (qemuExtDevicesInitPaths(driver, vm->def) < 0) {
> -ret = -1;
> -goto cleanup;
> -}
> -
> -ret = virDomainCheckDeviceChanges(vm->def, def);
> -
> - cleanup:
> -virDomainObjEndAPI();
> -
> -return ret;
> -}
> -
>  static virDomainPtr
>  qemuDomainDefineXMLFlags(virConnectPtr conn,
>   const char *xml,
> @@ -7820,9 +7795,6 @@ qemuDomainDefineXMLFlags(virConnectPtr conn,
>  if (virDomainDefineXMLFlagsEnsureACL(conn, def) < 0)
>  goto cleanup;
>
> -if (qemuDomainCheckDeviceChanges(driver, def) < 0)
> -goto cleanup;
> -
>  if (!(vm = virDomainObjListAdd(driver->domains, def,
> driver->xmlopt,
> 0, )))
> diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
> index af52466421..dc032aa60c 100644
> --- a/src/qemu/qemu_extdevice.c
> +++ b/src/qemu/qemu_extdevice.c
> @@ -79,7 +79,7 @@ qemuExtDeviceLogCommand(qemuDomainLogContextPtr logCtxt,
>   * stored and we can remove directories and files in case of domain XML
>   * changes.
>   */
> -int
> +static int
>  qemuExtDevicesInitPaths(virQEMUDriverPtr driver,
>  virDomainDefPtr def)
>  {
> diff --git a/src/qemu/qemu_extdevice.h b/src/qemu/qemu_extdevice.h
> index 5a53c79f38..039b3e60dd 100644
> --- a/src/qemu/qemu_extdevice.h
> +++ b/src/qemu/qemu_extdevice.h
> @@ -54,6 +54,3 @@ bool qemuExtDevicesHasDevice(virDomainDefPtr def);
>  int qemuExtDevicesSetupCgroup(virQEMUDriverPtr driver,
>virDomainDefPtr def,
>virCgroupPtr cgroup);
> -
> -int qemuExtDevicesInitPaths(virQEMUDriverPtr driver,
> -virDomainDefPtr def);
> --
> 2.19.2
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv2 09/11] util: Extend virresctl API to retrieve multiple monitor statistics

[Marc-André Lureau]

 ATTRIBUTE_UNUSED,
>  if (qemuDomainGetStatsCpuCgroup(dom, record, maxparams) < 0)
>  return -1;
>
> -if (qemuDomainGetStatsCpuCache(dom, record, maxparams) < 0)
> +if (qemuDomainGetStatsCpuCache(driver, dom, record, maxparams) < 0)
>  return -1;
>
>  return 0;
> diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c
> index 0117b8f..80acb70 100644
> --- a/src/util/virresctrl.c
> +++ b/src/util/virresctrl.c
> @@ -2669,8 +2669,7 @@ virResctrlMonitorStatsSorter(const void *a,
>   * virResctrlMonitorGetStats
>   *
>   * @monitor: The monitor that the statistic data will be retrieved from.
> - * @resource: The name for resource name. 'llc_occupancy' for cache resource.
> - * "mbm_total_bytes" and "mbm_local_bytes" for memory bandwidth resource.
> + * @resources: A string list for the monitor feature names.
>   * @stats: Pointer of of virResctrlMonitorStatsPtr array for holding cache or
>   * memory bandwidth usage data.
>   * @nstats: A size_t pointer to hold the returned array length of @stats
> @@ -2679,14 +2678,15 @@ virResctrlMonitorStatsSorter(const void *a,
>   *
>   * Returns 0 on success, -1 on error.
>   */
> -static int
> +int
>  virResctrlMonitorGetStats(virResctrlMonitorPtr monitor,
> -  const char *resource,
> +  const char **resources,
>virResctrlMonitorStatsPtr **stats,
>size_t *nstats)
>  {
>  int rv = -1;
>  int ret = -1;
> +size_t i = 0;
>  unsigned int val = 0;
>  DIR *dirp = NULL;
>  char *datapath = NULL;
> @@ -2744,21 +2744,23 @@ virResctrlMonitorGetStats(virResctrlMonitorPtr 
> monitor,
>  if (virStrToLong_uip(node_id, NULL, 0, >id) < 0)
>  goto cleanup;
>
> -rv = virFileReadValueUint(, "%s/%s/%s", datapath,
> -  ent->d_name, resource);
> -if (rv == -2) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("File '%s/%s/%s' does not exist."),
> -   datapath, ent->d_name, resource);
> -}
> -if (rv < 0)
> -goto cleanup;
> +for (i = 0; resources[i]; i++) {
> +rv = virFileReadValueUint(, "%s/%s/%s", datapath,
> +  ent->d_name, resources[i]);
> +if (rv == -2) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("File '%s/%s/%s' does not exist."),
> +   datapath, ent->d_name, resources[i]);
> +}
> +if (rv < 0)
> +goto cleanup;
>
> -if (VIR_APPEND_ELEMENT(stat->vals, stat->nvals, val) < 0)
> -goto cleanup;
> +if (VIR_APPEND_ELEMENT(stat->vals, stat->nvals, val) < 0)
> +goto cleanup;
>
> -if (virStringListAdd(>features, resource) < 0)
> -goto cleanup;
> +if (virStringListAdd(>features, resources[i]) < 0)
> +goto cleanup;
> +}
>
>  if (VIR_APPEND_ELEMENT(*stats, *nstats, stat) < 0)
>  goto cleanup;
> @@ -2808,6 +2810,10 @@ 
> virResctrlMonitorGetCacheOccupancy(virResctrlMonitorPtr monitor,
> virResctrlMonitorStatsPtr **stats,
> size_t *nstats)
>  {
> -return virResctrlMonitorGetStats(monitor, "llc_occupancy",
> - stats, nstats);
> +int ret = -1;
> +const char *features[2] = {"llc_occupancy", NULL};
> +
> +ret = virResctrlMonitorGetStats(monitor, features, stats, nstats);
> +
> +return ret;
>  }
> diff --git a/src/util/virresctrl.h b/src/util/virresctrl.h
> index 4dabb9c..9ef51b7 100644
> --- a/src/util/virresctrl.h
> +++ b/src/util/virresctrl.h
> @@ -236,6 +236,12 @@ int
>  virResctrlMonitorRemove(virResctrlMonitorPtr monitor);
>
>  int
> +virResctrlMonitorGetStats(virResctrlMonitorPtr monitor,
> +  const char **resources,
> +  virResctrlMonitorStatsPtr **stats,
> +  size_t *nstats);
> +
> +int
>  virResctrlMonitorGetCacheOccupancy(virResctrlMonitorPtr monitor,
> virResctrlMonitorStatsPtr **stats,
> size_t *nstats);
> --
> 2.7.4
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/19] Add vhost-user-gpu support

[Marc-André Lureau]

Hi

On Wed, Jun 5, 2019 at 2:32 PM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> This series of patches adds support for running virtio GPUs in
> seperate processes, thanks to vhost-user backend.
>
> The QEMU support landed for 4.1. There are several benefits of running
> the GPU/virgl in an external process, since Mesa is rather heavy on
> the qemu main loop, and may block for a while, or crash.
>
> The external GPU process is started with one end of a socket pair, the
> other end is given to a QEMU chardev attached to a device. The
> external process is also added to the cgroup to limit resources usage.
>
> Thanks
>
> Since RFC:
> - discover helpers following the vhost-user spec
> - change vhost-user  model for a vhostuser attribute
> - add a patch to specify the rendernode on 
> - change the way command line is built, following qemu series changes
> - socket labeling
> - a few cleanup patches
> - rebased

Can I get some reviews before I respin the series?

thanks

>
> Marc-André Lureau (19):
>   device-conf: removed unneeded virDomainDeviceInfoCopy()
>   tpm: minor argument comment fix
>   qemu_firmware: only set nfeatures on success
>   qemu: extract out qemuFetchConfigs from firmware
>   domain: add "vhostuser" attribute to virtio video model
>   domain: add rendernode attribute on 
>   qemu-cgroup: allow accel rendernode access
>   qemu: add vhost-user-gpu capabilities checks
>   qemu: check that qemu is vhost-user-vga capable
>   qemu: validate virtio-gpu with vhost-user
>   qemu: restrict 'virgl=' option to non-vhostuser video type
>   qemu: add vhost-user helpers
>   qemu: add qemuSecurityStartVhostUserGPU helper
>   qemu: add vhost-user-gpu helper unit
>   qemu: prepare domain for vhost-user GPU
>   qemu: start/stop the vhost-user-gpu external device
>   qemu: build vhost-user GPU devices
>   tests: mock execv/execve
>   tests: add vhost-user-gpu xml2argv tests
>
>  docs/formatdomain.html.in |  11 +
>  docs/schemas/domaincommon.rng |  16 +-
>  src/conf/device_conf.c|  22 +-
>  src/conf/device_conf.h|   4 +-
>  src/conf/domain_conf.c|  33 +-
>  src/conf/domain_conf.h|   2 +
>  src/libvirt_private.syms  |   1 -
>  src/qemu/Makefile.inc.am  |   6 +
>  src/qemu/qemu_capabilities.c  |   6 +
>  src/qemu/qemu_capabilities.h  |   4 +
>  src/qemu/qemu_cgroup.c|  24 ++
>  src/qemu/qemu_command.c   |  54 ++-
>  src/qemu/qemu_configs.c   | 183 
>  src/qemu/qemu_configs.h   |  31 ++
>  src/qemu/qemu_domain.c|  10 +-
>  src/qemu/qemu_extdevice.c |  79 +++-
>  src/qemu/qemu_extdevice.h |   5 +
>  src/qemu/qemu_firmware.c  | 146 +--
>  src/qemu/qemu_process.c   |  18 +-
>  src/qemu/qemu_security.c  |  48 +++
>  src/qemu/qemu_security.h  |   6 +
>  src/qemu/qemu_tpm.c   |   2 +-
>  src/qemu/qemu_vhost_user.c| 395 ++
>  src/qemu/qemu_vhost_user.h|  51 +++
>  src/qemu/qemu_vhost_user_gpu.c| 307 ++
>  src/qemu/qemu_vhost_user_gpu.h|  54 +++
>  tests/Makefile.am |   9 +
>  .../etc/qemu/vhost-user/40-gpu.json   |   1 +
>  .../etc/qemu/vhost-user/50-gpu.json   |   0
>  .../qemu/vhost-user/test-vhost-user-gpu   |  11 +
>  .../usr/share/qemu/vhost-user/30-gpu.json |   1 +
>  .../usr/share/qemu/vhost-user/50-gpu.json |   8 +
>  .../usr/share/qemu/vhost-user/60-gpu.json |   1 +
>  tests/qemuvhostusertest.c | 132 ++
>  .../vhost-user-gpu-secondary.args |  35 ++
>  .../vhost-user-gpu-secondary.xml  |  44 ++
>  tests/qemuxml2argvdata/vhost-user-vga.args|  32 ++
>  tests/qemuxml2argvdata/vhost-user-vga.xml |  41 ++
>  tests/qemuxml2argvtest.c  |  21 +
>  tests/virfilewrapper.c|  22 +
>  40 files changed, 1690 insertions(+), 186 deletions(-)
>  create mode 100644 src/qemu/qemu_configs.c
>  create mode 100644 src/qemu/qemu_configs.h
>  create mode 100644 src/qemu/qemu_vhost_user.c
>  create mode 100644 src/qemu/qemu_vhost_user.h
>  create mode 100644 src/qemu/qemu_vhost_user_gpu.c
>  create mode 100644 src/qemu/qemu_vhost_user_gpu.h
>  create mode 12 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu

Re: [libvirt] [PATCH] tpm: Run swtpm_setup with less parameters on incoming migration

[Marc-André Lureau]

Hi

On Sat, Jul 27, 2019 at 12:41 AM Stefan Berger  wrote:
>
> In case of an incoming migration we do not need to run swtpm_setup
> with all the parameters but only want to get the benefit of it
> creating a TPM state file for us that we can then label with an
> SELinux label. The actual state will be overwritten by the in-
> coming state. So we have to pass an indicator for incomingMigration
> all the way to the command line parameter generation for swtpm_setup.
>
> Signed-off-by: Stefan Berger 

iirc, I needed to pass it down as well in my slirp-helper series.

Reviewed-by: Marc-André Lureau 

> ---
>  src/qemu/qemu_extdevice.c |  5 ++--
>  src/qemu/qemu_extdevice.h |  3 ++-
>  src/qemu/qemu_process.c   |  2 +-
>  src/qemu/qemu_tpm.c   | 49 +--
>  src/qemu/qemu_tpm.h   |  3 ++-
>  5 files changed, 40 insertions(+), 22 deletions(-)
>
> diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
> index e576bca165..af52466421 100644
> --- a/src/qemu/qemu_extdevice.c
> +++ b/src/qemu/qemu_extdevice.c
> @@ -128,7 +128,8 @@ qemuExtDevicesCleanupHost(virQEMUDriverPtr driver,
>  int
>  qemuExtDevicesStart(virQEMUDriverPtr driver,
>  virDomainObjPtr vm,
> -qemuDomainLogContextPtr logCtxt)
> +qemuDomainLogContextPtr logCtxt,
> +bool incomingMigration)
>  {
>  int ret = 0;
>
> @@ -136,7 +137,7 @@ qemuExtDevicesStart(virQEMUDriverPtr driver,
>  return -1;
>
>  if (vm->def->tpm)
> -ret = qemuExtTPMStart(driver, vm, logCtxt);
> +ret = qemuExtTPMStart(driver, vm, logCtxt, incomingMigration);
>
>  return ret;
>  }
> diff --git a/src/qemu/qemu_extdevice.h b/src/qemu/qemu_extdevice.h
> index bbdb9a1cc2..5a53c79f38 100644
> --- a/src/qemu/qemu_extdevice.h
> +++ b/src/qemu/qemu_extdevice.h
> @@ -40,7 +40,8 @@ void qemuExtDevicesCleanupHost(virQEMUDriverPtr driver,
>
>  int qemuExtDevicesStart(virQEMUDriverPtr driver,
>  virDomainObjPtr vm,
> -qemuDomainLogContextPtr logCtxt)
> +qemuDomainLogContextPtr logCtxt,
> +bool incomingMigration)
>  ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3)
>  ATTRIBUTE_RETURN_CHECK;
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 75205bc121..fae18824ba 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -6774,7 +6774,7 @@ qemuProcessLaunch(virConnectPtr conn,
>  if (qemuProcessGenID(vm, flags) < 0)
>  goto cleanup;
>
> -if (qemuExtDevicesStart(driver, vm, logCtxt) < 0)
> +if (qemuExtDevicesStart(driver, vm, logCtxt, incoming != NULL) < 0)
>  goto cleanup;
>
>  VIR_DEBUG("Building emulator command line");
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 77ef601f74..4174aa4c62 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -453,6 +453,7 @@ qemuTPMSetupEncryption(const unsigned char *secretuuid,
>   *   for the user given by userid or 'tss'
>   * @tpmversion: The version of the TPM, either a TPM 1.2 or TPM 2
>   * @encryption: pointer to virStorageEncryption holding secret
> + * @incomingMigration: whether we have an incoming migration
>   *
>   * Setup the external swtpm by creating endorsement key and
>   * certificates for it.
> @@ -466,7 +467,8 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  gid_t swtpm_group,
>  const char *logfile,
>  const virDomainTPMVersion tpmversion,
> -const unsigned char *secretuuid)
> +const unsigned char *secretuuid,
> +bool incomingMigration)
>  {
>  virCommandPtr cmd = NULL;
>  int exitstatus;
> @@ -525,16 +527,23 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  pwdfile_fd = -1;
>  }
>
> -virCommandAddArgList(cmd,
> - "--tpm-state", storagepath,
> - "--vmid", vmid,
> - "--logfile", logfile,
> - "--createek",
> - "--create-ek-cert",
> - "--create-platform-cert",
> - "--lock-nvram",
> - "--not-overwrite",
> - NULL);
> +if (!incomingMigration) {
> +virCommandAddArgList(cmd,
> + "--tpm-st

Re: [libvirt] [PATCH 00/19] Add vhost-user-gpu support

[Marc-André Lureau]

Hi!

ping

On Wed, Jun 5, 2019 at 2:32 PM  wrote:
>
> From: Marc-André Lureau 
>
> Hi,
>
> This series of patches adds support for running virtio GPUs in
> seperate processes, thanks to vhost-user backend.
>
> The QEMU support landed for 4.1. There are several benefits of running
> the GPU/virgl in an external process, since Mesa is rather heavy on
> the qemu main loop, and may block for a while, or crash.
>
> The external GPU process is started with one end of a socket pair, the
> other end is given to a QEMU chardev attached to a device. The
> external process is also added to the cgroup to limit resources usage.
>
> Thanks
>
> Since RFC:
> - discover helpers following the vhost-user spec
> - change vhost-user  model for a vhostuser attribute
> - add a patch to specify the rendernode on 
> - change the way command line is built, following qemu series changes
> - socket labeling
> - a few cleanup patches
> - rebased
>
> Marc-André Lureau (19):
>   device-conf: removed unneeded virDomainDeviceInfoCopy()
>   tpm: minor argument comment fix
>   qemu_firmware: only set nfeatures on success
>   qemu: extract out qemuFetchConfigs from firmware
>   domain: add "vhostuser" attribute to virtio video model
>   domain: add rendernode attribute on 
>   qemu-cgroup: allow accel rendernode access
>   qemu: add vhost-user-gpu capabilities checks
>   qemu: check that qemu is vhost-user-vga capable
>   qemu: validate virtio-gpu with vhost-user
>   qemu: restrict 'virgl=' option to non-vhostuser video type
>   qemu: add vhost-user helpers
>   qemu: add qemuSecurityStartVhostUserGPU helper
>   qemu: add vhost-user-gpu helper unit
>   qemu: prepare domain for vhost-user GPU
>   qemu: start/stop the vhost-user-gpu external device
>   qemu: build vhost-user GPU devices
>   tests: mock execv/execve
>   tests: add vhost-user-gpu xml2argv tests
>
>  docs/formatdomain.html.in |  11 +
>  docs/schemas/domaincommon.rng |  16 +-
>  src/conf/device_conf.c|  22 +-
>  src/conf/device_conf.h|   4 +-
>  src/conf/domain_conf.c|  33 +-
>  src/conf/domain_conf.h|   2 +
>  src/libvirt_private.syms  |   1 -
>  src/qemu/Makefile.inc.am  |   6 +
>  src/qemu/qemu_capabilities.c  |   6 +
>  src/qemu/qemu_capabilities.h  |   4 +
>  src/qemu/qemu_cgroup.c|  24 ++
>  src/qemu/qemu_command.c   |  54 ++-
>  src/qemu/qemu_configs.c   | 183 
>  src/qemu/qemu_configs.h   |  31 ++
>  src/qemu/qemu_domain.c|  10 +-
>  src/qemu/qemu_extdevice.c |  79 +++-
>  src/qemu/qemu_extdevice.h |   5 +
>  src/qemu/qemu_firmware.c  | 146 +--
>  src/qemu/qemu_process.c   |  18 +-
>  src/qemu/qemu_security.c  |  48 +++
>  src/qemu/qemu_security.h  |   6 +
>  src/qemu/qemu_tpm.c   |   2 +-
>  src/qemu/qemu_vhost_user.c| 395 ++
>  src/qemu/qemu_vhost_user.h|  51 +++
>  src/qemu/qemu_vhost_user_gpu.c| 307 ++
>  src/qemu/qemu_vhost_user_gpu.h|  54 +++
>  tests/Makefile.am |   9 +
>  .../etc/qemu/vhost-user/40-gpu.json   |   1 +
>  .../etc/qemu/vhost-user/50-gpu.json   |   0
>  .../qemu/vhost-user/test-vhost-user-gpu   |  11 +
>  .../usr/share/qemu/vhost-user/30-gpu.json |   1 +
>  .../usr/share/qemu/vhost-user/50-gpu.json |   8 +
>  .../usr/share/qemu/vhost-user/60-gpu.json |   1 +
>  tests/qemuvhostusertest.c | 132 ++
>  .../vhost-user-gpu-secondary.args |  35 ++
>  .../vhost-user-gpu-secondary.xml  |  44 ++
>  tests/qemuxml2argvdata/vhost-user-vga.args|  32 ++
>  tests/qemuxml2argvdata/vhost-user-vga.xml |  41 ++
>  tests/qemuxml2argvtest.c  |  21 +
>  tests/virfilewrapper.c|  22 +
>  40 files changed, 1690 insertions(+), 186 deletions(-)
>  create mode 100644 src/qemu/qemu_configs.c
>  create mode 100644 src/qemu/qemu_configs.h
>  create mode 100644 src/qemu/qemu_vhost_user.c
>  create mode 100644 src/qemu/qemu_vhost_user.h
>  create mode 100644 src/qemu/qemu_vhost_user_gpu.c
>  create mode 100644 src/qemu/qemu_vhost_user_gpu.h
>  create mode 12 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json
>  create mode 100644 tests/qemuvhostuserdata/etc/qemu/vh

Re: [libvirt] [PATCH v2 13/21] utils: Implement function to pass a buffer to send via a fd to virCommand

[Marc-André Lureau]

On Wed, Jul 10, 2019 at 10:12 PM Stefan Berger
 wrote:
>
> Implement virCommandSetSendBuffer() that allows the caller to pass a
> file descriptor and buffer to virCommand. virCommand will write the
> buffer into the file descriptor. That file descriptor could be the
> write end of a pipe or one of the file descriptors of a socketpair.
> The other file descriptor should be passed to the launched process to
> read the data from.
>
> Only implement the function to allocate memory for send buffers
> and to free them later on.
>
> Signed-off-by: Stefan Berger 

that looks fine,
Reviewed-by: Marc-André Lureau 

> ---
>  src/libvirt_private.syms |  1 +
>  src/util/vircommand.c| 62 
>  src/util/vircommand.h|  5 
>  3 files changed, 68 insertions(+)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index d2045895a1..3feb862fb4 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1734,6 +1734,7 @@ virCommandSetOutputBuffer;
>  virCommandSetOutputFD;
>  virCommandSetPidFile;
>  virCommandSetPreExecHook;
> +virCommandSetSendBuffer;
>  virCommandSetSELinuxLabel;
>  virCommandSetUID;
>  virCommandSetUmask;
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 8695c98d1b..e32377497b 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -77,6 +77,16 @@ struct _virCommandFD {
>  unsigned int flags;
>  };
>
> +typedef struct _virCommandSendBuffer virCommandSendBuffer;
> +typedef virCommandSendBuffer *virCommandSendBufferPtr;
> +
> +struct _virCommandSendBuffer {
> +int fd;
> +unsigned char *buffer;
> +size_t buflen;
> +off_t offset;
> +};
> +
>  struct _virCommand {
>  int has_error; /* ENOMEM on allocation failure, -1 for anything else.  */
>
> @@ -136,6 +146,9 @@ struct _virCommand {
>  char *appArmorProfile;
>  #endif
>  int mask;
> +
> +virCommandSendBufferPtr sendBuffers;
> +size_t numSendBuffers;
>  };
>
>  /* See virCommandSetDryRun for description for this variable */
> @@ -1741,6 +1754,53 @@ virCommandSetWorkingDirectory(virCommandPtr cmd, const 
> char *pwd)
>  }
>
>
> +static void
> +virCommandFreeSendBuffers(virCommandPtr cmd)
> +{
> +size_t i;
> +
> +for (i = 0; i < cmd->numSendBuffers; i++) {
> +VIR_FORCE_CLOSE(cmd->sendBuffers[i].fd);
> +VIR_FREE(cmd->sendBuffers[i].buffer);
> +}
> +VIR_FREE(cmd->sendBuffers);
> +}
> +
> +
> +/**
> + * virCommandSetSendBuffer
> + * @cmd: the command to modify
> + *
> + * Pass a buffer to virCommand that will be written into the
> + * given file descriptor. The buffer will be freed automatically
> + * and the file descriptor closed.
> + */
> +int
> +virCommandSetSendBuffer(virCommandPtr cmd,
> +int fd,
> +unsigned char *buffer, size_t buflen)
> +{
> +size_t i = cmd->numSendBuffers;
> +
> +if (!cmd || cmd->has_error)
> +return -1;
> +
> +if (VIR_REALLOC_N(cmd->sendBuffers, i + 1) < 0) {
> +cmd->has_error = ENOMEM;
> +return -1;
> +}
> +
> +cmd->sendBuffers[i].fd = fd;
> +cmd->sendBuffers[i].buffer = buffer;
> +cmd->sendBuffers[i].buflen = buflen;
> +cmd->sendBuffers[i].offset = 0;
> +
> +cmd->numSendBuffers++;
> +
> +return 0;
> +}
> +
> +
>  /**
>   * virCommandSetInputBuffer:
>   * @cmd: the command to modify
> @@ -2880,6 +2940,8 @@ virCommandFree(virCommandPtr cmd)
>  VIR_FREE(cmd->appArmorProfile);
>  #endif
>
> +virCommandFreeSendBuffers(cmd);
> +
>  VIR_FREE(cmd);
>  }
>
> diff --git a/src/util/vircommand.h b/src/util/vircommand.h
> index c9a8d3c41c..716e84af3d 100644
> --- a/src/util/vircommand.h
> +++ b/src/util/vircommand.h
> @@ -148,6 +148,11 @@ void virCommandAddArgList(virCommandPtr cmd,
>  void virCommandSetWorkingDirectory(virCommandPtr cmd,
> const char *pwd) ATTRIBUTE_NONNULL(2);
>
> +int virCommandSetSendBuffer(virCommandPtr cmd,
> +int fd,
> +unsigned char *buffer, size_t buflen)
> +ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(3);
> +
>  void virCommandSetInputBuffer(virCommandPtr cmd,
>const char *inbuf) ATTRIBUTE_NONNULL(2);
>
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 15/21] utils: Write a maximum of MAX_PIPE_FEED_BYTES into a pipe

[Marc-André Lureau]

On Wed, Jul 10, 2019 at 10:12 PM Stefan Berger
 wrote:
>
> To avoid blocking on a write on a pipe that the receiving process
> does not read from, write only MAX_PIPE_FEED_BYTES into the pipe
> so that we can serve other pipes as well.

why not simply use non-blocking write?

>
> Signed-off-by: Stefan Berger 
> ---
>  src/util/vircommand.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 898ee0df45..0e367eeeab 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -86,6 +86,8 @@ struct _virCommandSendBuffer {
>  size_t buflen;
>  off_t offset;
>  };
> +/* max. number of bytes we write to pipe to avoid blocking on it */
> +#define MAX_PIPE_FEED_BYTES 1024
>
>  struct _virCommand {
>  int has_error; /* ENOMEM on allocation failure, -1 for anything else.  */
> @@ -2237,7 +2239,7 @@ virCommandProcessIO(virCommandPtr cmd)
>  int done;
>
>  done = write(cmd->inpipe, cmd->inbuf + inoff,
> - inlen - inoff);
> + MIN(inlen - inoff, MAX_PIPE_FEED_BYTES));
>  if (done < 0) {
>  if (errno == EPIPE) {
>  VIR_DEBUG("child closed stdin early, ignoring EPIPE "
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 16/21] utils: Extend virCommandProcessIO to including the send buffers

[Marc-André Lureau]

On Wed, Jul 10, 2019 at 10:12 PM Stefan Berger
 wrote:
>
> Signed-off-by: Stefan Berger 

Could you include a test?

> ---
>  src/util/vircommand.c | 70 ++-
>  1 file changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 0e367eeeab..357a9888a1 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -1803,6 +1803,69 @@ virCommandSetSendBuffer(virCommandPtr cmd,
>  }
>
>
> +static int
> +virCommandGetNumSendBuffers(virCommandPtr cmd)
> +{
> +return cmd->numSendBuffers;
> +}
> +

That getter doesn't seem very useful, or at least you don't use it consistently.

looks good otherwise

> +
> +static int
> +virCommandAddSendBuffersFillPollfd(virCommandPtr cmd,
> +   struct pollfd *fds,
> +   int startidx)
> +{
> +size_t i, j;
> +
> +for (i = 0, j = 0; i < cmd->numSendBuffers; i++) {
> +if (cmd->sendBuffers[i].fd >= 0) {
> +fds[startidx + j].fd = cmd->sendBuffers[i].fd;
> +fds[startidx + j].events = POLLOUT;
> +fds[startidx + j].revents = 0;
> +j++;
> +}
> +}
> +
> +return j;
> +}
> +
> +
> +static int
> +virCommandSendBuffersHandlePoll(virCommandPtr cmd,
> +struct pollfd *fds)
> +{
> +size_t i;
> +int done;
> +
> +for (i = 0; i < cmd->numSendBuffers; i++) {
> +if (fds->fd == cmd->sendBuffers[i].fd)
> +break;
> +}
> +if (i == cmd->numSendBuffers)
> +return 0;
> +
> +done = write(fds->fd,
> + cmd->sendBuffers[i].buffer + cmd->sendBuffers[i].offset,
> + MIN(cmd->sendBuffers[i].buflen - cmd->sendBuffers[i].offset,
> + MAX_PIPE_FEED_BYTES));
> +if (done < 0) {
> +if (errno == EPIPE) {
> +VIR_DEBUG("child closed PIPE early, ignoring EPIPE "
> +  "on fd %d", cmd->sendBuffers[i].fd);
> +VIR_FORCE_CLOSE(cmd->sendBuffers[i].fd);
> +} else if (errno != EINTR && errno != EAGAIN) {
> +virReportSystemError(errno, "%s",
> + _("unable to write to child input"));
> +return -1;
> +}
> +} else {
> +cmd->sendBuffers[i].offset += done;
> +if (cmd->sendBuffers[i].offset == cmd->sendBuffers[i].buflen)
> +VIR_FORCE_CLOSE(cmd->sendBuffers[i].fd);
> +}
> +return 0;
> +}
> +
>  /**
>   * virCommandSetInputBuffer:
>   * @cmd: the command to modify
> @@ -2157,7 +2220,7 @@ virCommandProcessIO(virCommandPtr cmd)
>  goto cleanup;
>  ret = -1;
>
> -if (VIR_ALLOC_N(fds, 3) < 0)
> +if (VIR_ALLOC_N(fds, 3 + virCommandGetNumSendBuffers(cmd)) < 0)
>  goto cleanup;
>
>  for (;;) {
> @@ -2183,6 +2246,8 @@ virCommandProcessIO(virCommandPtr cmd)
>  nfds++;
>  }
>
> +nfds += virCommandAddSendBuffersFillPollfd(cmd, fds, nfds);
> +
>  if (nfds == 0)
>  break;
>
> @@ -2255,6 +2320,9 @@ virCommandProcessIO(virCommandPtr cmd)
>  if (inoff == inlen)
>  VIR_FORCE_CLOSE(cmd->inpipe);
>  }
> +} else if (fds[i].revents & (POLLOUT | POLLHUP | POLLERR)) {
> +if (virCommandSendBuffersHandlePoll(cmd, [i]) < 0)
> +goto cleanup;
>  }
>  }
>  }
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 14/21] utils: Convert pollfd array to be allocated

[Marc-André Lureau]

On Wed, Jul 10, 2019 at 10:12 PM Stefan Berger
 wrote:
>
> Convert the struct pollfd *fds to be allocated rather than residing
> on the stack.
>

why? give some context to the commit message. thanks

> Signed-off-by: Stefan Berger 
> ---
>  src/util/vircommand.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index e32377497b..898ee0df45 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -2123,6 +2123,7 @@ virCommandProcessIO(virCommandPtr cmd)
>  size_t inlen = 0, outlen = 0, errlen = 0;
>  size_t inoff = 0;
>  int ret = 0;
> +VIR_AUTOFREE(struct pollfd *) fds = NULL;
>
>  if (dryRunBuffer || dryRunCallback) {
>  VIR_DEBUG("Dry run requested, skipping I/O processing");
> @@ -2154,9 +2155,11 @@ virCommandProcessIO(virCommandPtr cmd)
>  goto cleanup;
>  ret = -1;
>
> +if (VIR_ALLOC_N(fds, 3) < 0)
> +goto cleanup;
> +
>  for (;;) {
>  size_t i;
> -struct pollfd fds[3];
>  int nfds = 0;
>
>  if (cmd->inpipe != -1) {
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 18/18] docs: Extend TPM docs with new encryption element

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Describe the encryption element in the TPM's domain XML.
>
> Signed-off-by: Stefan Berger 
> ---
>  docs/formatdomain.html.in | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index a7a6ec32a5..b53ea7d6f4 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -8212,6 +8212,9 @@ qemu-kvm -net nic,model=? /dev/null
>TPM functionality for each VM. QEMU talks to it over a Unix socket. 
> With
>the emulator device type each guest gets its own private TPM.
>'emulator' since 4.5.0
> +  The state of the TPM emulator can be encrypted by providing an
> +  encryption element.
> +  'encryption' since 5.5.0

here too, 5.6.0 I presume

Reviewed-by: Marc-André Lureau 

>  
>  
>   Example: usage of the TPM Emulator
> @@ -8221,6 +8224,9 @@ qemu-kvm -net nic,model=? /dev/null
>devices
>  tpm model='tpm-tis'
>backend type='emulator' version='2.0'
> +encryption format='vtpm'
> +  secret type='passphrase' usage='VTPM_example'/
> +/encryption
>/backend
>  /tpm
>/devices
> @@ -8283,6 +8289,16 @@ qemu-kvm -net nic,model=? /dev/null
>'2.0' : creates a TPM 2.0
>  
>
> +  encryption
> +  
> +
> +  The encryption element allows the state of a TPM 
> emulator
> +  to be encrypted. The format attribute must be 
> vtpm.
> +  The secret element must reference a secret object 
> using
> +  either its usage or uuid. The 
> type
> +  attribute must be set to passphrase.
> +
> +  
>  
>
>  NVRAM device
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 17/18] docs: Extend Secret XML documentation with vtpm usage type

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Extend the Secret XML documentation with vtpm usage type.
>
> Signed-off-by: Stefan Berger 
> ---
>  docs/formatsecret.html.in | 61 +--
>  1 file changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/docs/formatsecret.html.in b/docs/formatsecret.html.in
> index defbe71731..aaa31bc76c 100644
> --- a/docs/formatsecret.html.in
> +++ b/docs/formatsecret.html.in
> @@ -42,8 +42,8 @@
>  Specifies what this secret is used for.  A mandatory
>  type attribute specifies the usage category, currently
>  only volume, ceph, iscsi,
> -and tls are defined. Specific usage categories
> -are described below.
> +tls, and vtpm are defined. Specific usage
> +categories are described below.
>
>  
>
> @@ -322,6 +322,63 @@ Secret 718c71bd-67b5-4a2b-87ec-a24e8ca200dc created
>  
>  # MYSECRET=`printf %s "letmein" | base64`
>  # virsh secret-set-value 718c71bd-67b5-4a2b-87ec-a24e8ca200dc $MYSECRET
> +Secret value set
> +
> +
> +
> +Usage type "vtpm"
> +
> +
> +  This secret is associated with a virtualized TPM (vTPM) and serves
> +  as a passphrase for deriving a key from for encrypting the state
> +  of the vTPM.
> +  The usage type='vtpm' element must contain
> +  a single name element that specifies a usage name
> +  for the secret.  The vTPM secret can then be used by UUID or by
> +  this usage name via the encryption element of
> +  a tpm when using an
> +  emulator.
> +  Since 5.5.0. The following is an example

will need to be updated, I guess 5.6.0 ?

> +  of the steps to be taken.  First create a vtpm-secret.xml file:
> +
> +
> +# cat vtpm-secret.xml
> +secret ephemeral='no' private='yes'
> +   descriptionsample vTPM secret/description
> +   usage type='vtpm'
> +  nameVTPM_example/name
> +   /usage
> +/secret
> +
> +# virsh secret-define vtpm-secret.xml
> +Secret 6dd3e4a5-1d76-44ce-961f-f119f5aad935 created
> +
> +# virsh secret-list
> + UUID   Usage
> +
> + 6dd3e4a5-1d76-44ce-961f-f119f5aad935   vtpm VTPM_example
> +
> +#
> +
> +
> +
> +
> +  A secret may also be defined via the
> +  
> +   virSecretDefineXML API.
> +
> +  Once the secret is defined, a secret value will need to be set. The
> +  secret would be the passphrase used to decrypt the vTPM state.
> +  The following is a simple example of using
> +  virsh secret-set-value to set the secret value. The
> +  
> +  virSecretSetValue API may also be used to set
> +  a more secure secret without using printable/readable characters.
> +
> +
> +
> +# MYSECRET=`printf %s "open sesame" | base64`
> +# virsh secret-set-value 6dd3e4a5-1d76-44ce-961f-f119f5aad935 $MYSECRET
>  Secret value set
>
>  
> --
> 2.20.1
>
Reviewed-by: Marc-André Lureau 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 14/18] tpm: Use fd to pass password to swtpm_setup and swtpm

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Allow vTPM state encryption when swtpm_setup and swtpm support
> passing a passphrase using a file descriptor.
>
> This patch enables the encryption of the vTPM state only. It does
> not encrypt the state during migration, so the destination secret
> does not need to have the same password at this point.

You could add that it is addressed in the following patch

>
> Signed-off-by: Stefan Berger 
> ---
>  src/libvirt_private.syms |   2 +
>  src/qemu/qemu_tpm.c  | 101 ++-
>  src/tpm/virtpm.c |  16 +++
>  src/tpm/virtpm.h |   3 ++
>  4 files changed, 120 insertions(+), 2 deletions(-)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index d2045895a1..d693f7facb 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1456,6 +1456,8 @@ virTPMEmulatorInit;
>  virTPMGetSwtpm;
>  virTPMGetSwtpmIoctl;
>  virTPMGetSwtpmSetup;
> +virTPMSwtpmCapsGet;
> +virTPMSwtpmSetupCapsGet;
>
>
>  # util/viralloc.h
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 2afa8db448..6e7d38b7e0 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -43,6 +43,8 @@
>  #include "dirname.h"
>  #include "qemu_tpm.h"
>  #include "virtpm.h"
> +#include "secret_util.h"
> +#include "virtpm_conf.h"
>
>  #define VIR_FROM_THIS VIR_FROM_NONE
>
> @@ -372,6 +374,60 @@ qemuTPMEmulatorPrepareHost(virDomainTPMDefPtr tpm,
>  return ret;
>  }
>
> +/*
> + * qemuTPMSetupEncryption
> + *
> + * @encryption: pointer to virStorageEncryption holding secret
> + *
> + * Returns file descriptor representing the read-end of a pipe.
> + * The passphrase can be read from this pipe. Returns < 0 in case
> + * of error.
> + *
> + * This function reads the passphrase and writes it into the
> + * write-end of a pipe so that the read-end of the pipe can be
> + * passed to the emulator for reading the passphrase from.
> + */
> +static int
> +qemuTPMSetupEncryption(virStorageEncryptionPtr encryption)
> +{
> +int ret = -1;
> +int pipefd[2] = { -1, -1 };
> +virConnectPtr conn;
> +uint8_t *secret = NULL;
> +size_t secret_len;
> +
> +conn = virGetConnectSecret();
> +if (!conn)
> +return -1;
> +
> +if (virSecretGetSecretString(conn, >secrets[0]->seclookupdef,
> + VIR_SECRET_USAGE_TYPE_VTPM,
> + , _len) < 0)
> +goto error;
> +
> +if (pipe(pipefd) == -1) {
> +virReportSystemError(errno, "%s",
> + _("Unable to create pipe"));
> +goto error;
> +}
> +
> +if (safewrite(pipefd[1], secret, secret_len) != secret_len)
> +goto error;

Hmm, I am not sure you can reliably buffer data on a pipe end and
close it before the other end read. Got any documentation pointer
about that?

> +
> +ret = pipefd[0];
> +
> + cleanup:
> +VIR_FREE(secret);
> +VIR_FORCE_CLOSE(pipefd[1]);
> +virObjectUnref(conn);
> +
> +return ret;
> +
> + error:
> +VIR_FORCE_CLOSE(pipefd[0]);
> +
> +goto cleanup;
> +}
>
>  /*
>   * qemuTPMEmulatorRunSetup
> @@ -386,6 +442,7 @@ qemuTPMEmulatorPrepareHost(virDomainTPMDefPtr tpm,
>   * @logfile: The file to write the log into; it must be writable
>   *   for the user given by userid or 'tss'
>   * @tpmversion: The version of the TPM, either a TPM 1.2 or TPM 2
> + * @encryption: pointer to virStorageEncryption holding secret
>   *
>   * Setup the external swtpm by creating endorsement key and
>   * certificates for it.
> @@ -398,13 +455,15 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  uid_t swtpm_user,
>  gid_t swtpm_group,
>  const char *logfile,
> -const virDomainTPMVersion tpmversion)
> +const virDomainTPMVersion tpmversion,
> +virStorageEncryptionPtr encryption)
>  {
>  virCommandPtr cmd = NULL;
>  int exitstatus;
>  int ret = -1;
>  char uuid[VIR_UUID_STRING_BUFLEN];
>  char *vmid = NULL;
> +int pwdfile_fd = -1;
>
>  if (!privileged && tpmversion == VIR_DOMAIN_TPM_VERSION_1_2)
>  return virFileWriteStr(logfile,
> @@ -434,6 +493,22 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>  break;
>  }
>
> +if (encryption) {
> +if (!virTPMSwtpmSetupCapsGet(
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD)) {
> +virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED,
> +_("%s does not support passing a passphrase using a file "
> +  "descriptor"), virTPMGetSwtpmSetup());
> +goto cleanup;
> +}
> +if ((pwdfile_fd = qemuTPMSetupEncryption(encryption)) < 0)
> +goto cleanup;
> +
> +virCommandAddArg(cmd, "--pwdfile-fd");
> +virCommandAddArgFormat(cmd, "%d", pwdfile_fd);
> +

Re: [libvirt] [PATCH 13/18] tpm: Parse the capabilities supported by swtpm and swtpm_setup

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Run 'swtpm socket --print-capabilities' and
> 'swtpm_setup --print-capabilities' to get the JSON object of the
> features the programs are supporting and parse them into a bitmap.
>
> Signed-off-by: Stefan Berger 
> ---
>  src/conf/Makefile.inc.am |   6 ++
>  src/conf/virtpm_conf.c   |  36 
>  src/conf/virtpm_conf.h   |  36 
>  src/libvirt_private.syms |   5 ++
>  src/tpm/Makefile.inc.am  |   5 +-
>  src/tpm/virtpm.c | 123 ++-
>  6 files changed, 209 insertions(+), 2 deletions(-)
>  create mode 100644 src/conf/virtpm_conf.c
>  create mode 100644 src/conf/virtpm_conf.h
>
> diff --git a/src/conf/Makefile.inc.am b/src/conf/Makefile.inc.am
> index 08c7c9da7f..e42425fcc5 100644
> --- a/src/conf/Makefile.inc.am
> +++ b/src/conf/Makefile.inc.am
> @@ -153,6 +153,11 @@ DEVICE_CONF_SOURCES = \
> conf/device_conf.h \
> $(NULL)
>
> +TPM_CONF_SOURCES = \
> +   conf/virtpm_conf.c \
> +   conf/virtpm_conf.h \
> +   $(NULL)
> +
>  CONF_SOURCES = \
> $(NETDEV_CONF_SOURCES) \
> $(DOMAIN_CONF_SOURCES) \
> @@ -171,6 +176,7 @@ CONF_SOURCES = \
> $(CPU_CONF_SOURCES) \
> $(CHRDEV_CONF_SOURCES) \
> $(DEVICE_CONF_SOURCES) \
> +   $(TPM_CONF_SOURCES) \
> $(NULL)
>
>  noinst_LTLIBRARIES += libvirt_conf.la
> diff --git a/src/conf/virtpm_conf.c b/src/conf/virtpm_conf.c
> new file mode 100644
> index 00..12e69e67b3
> --- /dev/null
> +++ b/src/conf/virtpm_conf.c
> @@ -0,0 +1,36 @@
> +/*
> + * virtpm_conf.c: vTPM XML processing
> + *
> + * Copyright (C) 2019 IBM Corporation
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library.  If not, see
> + * .
> + */
> +
> +#include 
> +
> +#include "virenum.h"
> +#include "virtpm_conf.h"
> +
> +#define VIR_FROM_THIS VIR_FROM_NONE
> +
> +VIR_ENUM_IMPL(virTPMSwtpmFeature,
> +  VIR_TPM_SWTPM_FEATURE_LAST,
> +  "cmdarg-pwd-fd",
> +);
> +
> +VIR_ENUM_IMPL(virTPMSwtpmSetupFeature,
> +  VIR_TPM_SWTPM_SETUP_FEATURE_LAST,
> +  "cmdarg-pwdfile-fd",
> +);
> diff --git a/src/conf/virtpm_conf.h b/src/conf/virtpm_conf.h
> new file mode 100644
> index 00..73c6c67271
> --- /dev/null
> +++ b/src/conf/virtpm_conf.h
> @@ -0,0 +1,36 @@
> +/*
> + * virtpm_conf.h: vTPM XML processing
> + *
> + * Copyright (C) 2019 IBM Corporation
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library.  If not, see
> + * .
> + */
> +
> +#pragma once
> +
> +typedef enum {
> +VIR_TPM_SWTPM_FEATURE_CMDARG_PWD_FD,
> +
> +VIR_TPM_SWTPM_FEATURE_LAST
> +} virTPMSwtpmFeature;
> +
> +typedef enum {
> +VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD,
> +
> +VIR_TPM_SWTPM_SETUP_FEATURE_LAST
> +} virTPMSwtpmSetupFeature;
> +
> +VIR_ENUM_DECL(virTPMSwtpmFeature);
> +VIR_ENUM_DECL(virTPMSwtpmSetupFeature);
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index e33d7d9f14..d2045895a1 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1236,6 +1236,11 @@ virStoragePoolObjVolumeGetNames;
>  virStoragePoolObjVolumeListExport;
>
>
> +# conf/virtpm_conf.h
> +virTPMSwtpmFeatureTypeFromString;
> +virTPMSwtpmSetupFeatureTypeFromString;
> +
> +
>  # cpu/cpu.h
>  cpuDecode;
>  cpuEncode;
> diff --git a/src/tpm/Makefile.inc.am b/src/tpm/Makefile.inc.am
> index 1f5131bf34..d8a15c406c 100644
> --- a/src/tpm/Makefile.inc.am
> +++ b/src/tpm/Makefile.inc.am
> @@ -12,6 +12,9 @@ EXTRA_DIST += \
>
>  noinst_LTLIBRARIES += libvirt_tpm.la
>  libvirt_la_BUILT_LIBADD += libvirt_tpm.la
> -libvirt_tpm_la_CFLAGS = $(AM_CFLAGS)
> +libvirt_tpm_la_CFLAGS = \
> +   -I$(srcdir)/conf \
> +   

Re: [libvirt] [PATCH 10/18] tpm: Move qemuTPMEmulatorInit to virTPMEmulatorInit in virtpm.c

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Move qemuTPMEmulatorInit to virTPMEmulatorInit in virtpm.c and introduce
> a few functions to query the executables needed for virCommands.
>
> Signed-off-by: Stefan Berger 

Couldn't there be a TOCTOU issue?

Anyway, for the move:
Reviewed-by: Marc-André Lureau 



> ---
>  src/libvirt_private.syms |  4 ++
>  src/qemu/qemu_tpm.c  | 83 
>  src/tpm/virtpm.c | 91 
>  src/tpm/virtpm.h |  5 +++
>  4 files changed, 108 insertions(+), 75 deletions(-)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index e29007cab1..e33d7d9f14 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1447,6 +1447,10 @@ virSecurityManagerVerify;
>
>  # tpm/virtpm.h
>  virTPMCreateCancelPath;
> +virTPMEmulatorInit;
> +virTPMGetSwtpm;
> +virTPMGetSwtpmIoctl;
> +virTPMGetSwtpmSetup;
>
>
>  # util/viralloc.h
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index cc8c69433b..61b4f72320 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -41,79 +41,12 @@
>  #include "configmake.h"
>  #include "dirname.h"
>  #include "qemu_tpm.h"
> +#include "virtpm.h"
>
>  #define VIR_FROM_THIS VIR_FROM_NONE
>
>  VIR_LOG_INIT("qemu.tpm");
>
> -/*
> - * executables for the swtpm; to be found on the host
> - */
> -static char *swtpm_path;
> -static char *swtpm_setup;
> -static char *swtpm_ioctl;
> -
> -/*
> - * qemuTPMEmulatorInit
> - *
> - * Initialize the Emulator functions by searching for necessary
> - * executables that we will use to start and setup the swtpm
> - */
> -static int
> -qemuTPMEmulatorInit(void)
> -{
> -if (!swtpm_path) {
> -swtpm_path = virFindFileInPath("swtpm");
> -if (!swtpm_path) {
> -virReportSystemError(ENOENT, "%s",
> - _("Unable to find 'swtpm' binary in 
> $PATH"));
> -return -1;
> -}
> -if (!virFileIsExecutable(swtpm_path)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("TPM emulator %s is not an executable"),
> -   swtpm_path);
> -VIR_FREE(swtpm_path);
> -return -1;
> -}
> -}
> -
> -if (!swtpm_setup) {
> -swtpm_setup = virFindFileInPath("swtpm_setup");
> -if (!swtpm_setup) {
> -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -   _("Could not find 'swtpm_setup' in PATH"));
> -return -1;
> -}
> -if (!virFileIsExecutable(swtpm_setup)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("'%s' is not an executable"),
> -   swtpm_setup);
> -VIR_FREE(swtpm_setup);
> -return -1;
> -}
> -}
> -
> -if (!swtpm_ioctl) {
> -swtpm_ioctl = virFindFileInPath("swtpm_ioctl");
> -if (!swtpm_ioctl) {
> -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -   _("Could not find swtpm_ioctl in PATH"));
> -return -1;
> -}
> -if (!virFileIsExecutable(swtpm_ioctl)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("swtpm_ioctl program %s is not an executable"),
> -   swtpm_ioctl);
> -VIR_FREE(swtpm_ioctl);
> -return -1;
> -}
> -}
> -
> -return 0;
> -}
> -
> -
>  /*
>   * qemuTPMCreateEmulatorStoragePath
>   *
> @@ -350,7 +283,7 @@ qemuTPMEmulatorGetPid(const char *swtpmStateDir,
>  if (!pidfile)
>  return -ENOMEM;
>
> -ret = virPidFileReadPathIfAlive(pidfile, pid, swtpm_path);
> +ret = virPidFileReadPathIfAlive(pidfile, pid, virTPMGetSwtpm());
>
>  VIR_FREE(pidfile);
>
> @@ -386,7 +319,7 @@ qemuTPMEmulatorPrepareHost(virDomainTPMDefPtr tpm,
>  {
>  int ret = -1;
>
> -if (qemuTPMEmulatorInit() < 0)
> +if (virTPMEmulatorInit() < 0)
>  return -1;
>
>  /* create log dir ... allow 'tss' user to cd into it */
> @@ -478,7 +411,7 @@ qemuTPMEmulatorRunSetup(const char *storagepath,
>   "this requires privileged mode for a "
>   "TPM 1.2\n"), 0600);
>
> -cmd = virCommandNew(swtpm

Re: [libvirt] [PATCH 12/18] tpm: Check whether previously found executables were updated

[Marc-André Lureau]

Hi

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Check whether previously found executables were updated and if
> so look for them again. This helps to use updated features of
> swtpm and its tools upon updating them.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  src/qemu/qemu_tpm.c |  1 +
>  src/tpm/virtpm.c| 34 ++
>  2 files changed, 35 insertions(+)
>
> diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c
> index 61b4f72320..2afa8db448 100644
> --- a/src/qemu/qemu_tpm.c
> +++ b/src/qemu/qemu_tpm.c
> @@ -20,6 +20,7 @@
>
>  #include 
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/src/tpm/virtpm.c b/src/tpm/virtpm.c
> index 0179b1e8be..e4735f9c4d 100644
> --- a/src/tpm/virtpm.c
> +++ b/src/tpm/virtpm.c
> @@ -77,8 +77,13 @@ virTPMCreateCancelPath(const char *devpath)
>   * executables for the swtpm; to be found on the host
>   */
>  static char *swtpm_path;
> +static struct stat swtpm_stat;
> +
>  static char *swtpm_setup;
> +static struct stat swtpm_setup_stat;
> +
>  static char *swtpm_ioctl;
> +static struct stat swtpm_ioctl_stat;
>
>  const char *
>  virTPMGetSwtpm(void)
> @@ -116,18 +121,22 @@ virTPMEmulatorInit(void)
>  static const struct {
>  const char *name;
>  char **path;
> +struct stat *stat;
>  } prgs[] = {
>  {
>  .name = "swtpm",
>  .path = _path,
> +.stat = _stat,
>  },
>  {
>  .name = "swtpm_setup",
>  .path = _setup,
> +.stat = _setup_stat,
>  },
>  {
>  .name = "swtpm_ioctl",
>  .path = _ioctl,
> +.stat = _ioctl_stat,
>  }
>  };
>  size_t i;
> @@ -135,6 +144,23 @@ virTPMEmulatorInit(void)
>  for (i = 0; i < ARRAY_CARDINALITY(prgs); i++) {
>  char *path;
>  bool findit = *prgs[i].path == NULL;
> +struct stat statbuf;
> +char *tmp;
> +
> +if (!findit) {
> +/* has executables changed? */
> +if (stat(*prgs[i].path, ) < 0) {
> +virReportSystemError(errno,
> + _("Could not stat %s"), path);
> +findit = true;
> +}
> +if (!findit &&
> +memcmp(_mtim,
> +   [i].stat->st_mtime,
> +   sizeof(statbuf.st_mtim))) {
> +findit = true;
> +}
> +}
>
>  if (findit) {
>  path = virFindFileInPath(prgs[i].name);
> @@ -151,7 +177,15 @@ virTPMEmulatorInit(void)
>  VIR_FREE(path);
>  return -1;
>  }
> +if (stat(path, prgs[i].stat) < 0) {
> +virReportSystemError(errno,
> + _("Could not stat %s"), path);
> +VIR_FREE(path);
> +return -1;
> +}
> +tmp = *prgs[i].path;
>  *prgs[i].path = path;
> +VIR_FREE(tmp);
>  }
>  }
>
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 09/18] tpm: Move virtpm.c from utils dir to own tpm dir

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Move virtpm.c from utils dir to its own tpm dir. This change
> is mostly driven by the later introduction of virtpm_conf.c where
> the define function like XYZTypeFromString() that we cannot
> include from utils dir.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 

> ---
>  po/POTFILES  |  2 +-
>  src/Makefile.am  |  1 +
>  src/conf/Makefile.inc.am |  1 +
>  src/libvirt_private.syms |  8 
>  src/qemu/Makefile.inc.am |  1 +
>  src/security/Makefile.inc.am |  1 +
>  src/tpm/Makefile.inc.am  | 17 +
>  src/{util => tpm}/virtpm.c   |  0
>  src/{util => tpm}/virtpm.h   |  0
>  src/util/Makefile.inc.am |  2 --
>  tests/Makefile.am|  1 +
>  11 files changed, 27 insertions(+), 7 deletions(-)
>  create mode 100644 src/tpm/Makefile.inc.am
>  rename src/{util => tpm}/virtpm.c (100%)
>  rename src/{util => tpm}/virtpm.h (100%)
>
> diff --git a/po/POTFILES b/po/POTFILES
> index 8017712ff4..e3c1a8edae 100644
> --- a/po/POTFILES
> +++ b/po/POTFILES
> @@ -188,6 +188,7 @@ src/storage/storage_backend_zfs.c
>  src/storage/storage_driver.c
>  src/storage/storage_util.c
>  src/test/test_driver.c
> +src/tpm/virtpm.c
>  src/util/iohelper.c
>  src/util/viralloc.c
>  src/util/virarptable.c
> @@ -266,7 +267,6 @@ src/util/virsysinfo.c
>  src/util/virthreadjob.c
>  src/util/virthreadpool.c
>  src/util/virtime.c
> -src/util/virtpm.c
>  src/util/virtypedparam.c
>  src/util/viruri.c
>  src/util/virusb.c
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0b562dc250..5f7c9001fe 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -122,6 +122,7 @@ include node_device/Makefile.inc.am
>  include secret/Makefile.inc.am
>  include storage/Makefile.inc.am
>  include remote/Makefile.inc.am
> +include tpm/Makefile.inc.am
>
>
>  THREAD_LIBS = $(LIB_PTHREAD) $(LTLIBMULTITHREAD)
> diff --git a/src/conf/Makefile.inc.am b/src/conf/Makefile.inc.am
> index 6b52ba674b..08c7c9da7f 100644
> --- a/src/conf/Makefile.inc.am
> +++ b/src/conf/Makefile.inc.am
> @@ -178,6 +178,7 @@ libvirt_la_BUILT_LIBADD += libvirt_conf.la
>  libvirt_conf_la_SOURCES = $(CONF_SOURCES)
>  libvirt_conf_la_CFLAGS = \
> -I$(srcdir)/conf \
> +   -I$(srcdir)/tpm \
> $(AM_CFLAGS) \
> $(NULL)
>  libvirt_conf_la_LDFLAGS = $(AM_LDFLAGS)
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 34937adc5d..e29007cab1 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1445,6 +1445,10 @@ virSecurityManagerTransactionStart;
>  virSecurityManagerVerify;
>
>
> +# tpm/virtpm.h
> +virTPMCreateCancelPath;
> +
> +
>  # util/viralloc.h
>  virAlloc;
>  virAllocN;
> @@ -3175,10 +3179,6 @@ virTimeStringThen;
>  virTimeStringThenRaw;
>
>
> -# util/virtpm.h
> -virTPMCreateCancelPath;
> -
> -
>  # util/virtypedparam.h
>  virTypedParameterAssign;
>  virTypedParameterAssignFromStr;
> diff --git a/src/qemu/Makefile.inc.am b/src/qemu/Makefile.inc.am
> index 254ba07dc0..72b28e731d 100644
> --- a/src/qemu/Makefile.inc.am
> +++ b/src/qemu/Makefile.inc.am
> @@ -84,6 +84,7 @@ libvirt_driver_qemu_impl_la_CFLAGS = \
> -I$(srcdir)/access \
> -I$(srcdir)/conf \
> -I$(srcdir)/secret \
> +   -I$(srcdir)/tpm \
> $(AM_CFLAGS) \
> $(NULL)
>  libvirt_driver_qemu_impl_la_LDFLAGS = $(AM_LDFLAGS)
> diff --git a/src/security/Makefile.inc.am b/src/security/Makefile.inc.am
> index 64e0f46857..3e110596dc 100644
> --- a/src/security/Makefile.inc.am
> +++ b/src/security/Makefile.inc.am
> @@ -47,6 +47,7 @@ noinst_LTLIBRARIES += libvirt_security_manager.la
>  libvirt_la_BUILT_LIBADD += libvirt_security_manager.la
>  libvirt_security_manager_la_CFLAGS = \
> -I$(srcdir)/conf \
> +   -I$(srcdir)/tpm \
> $(AM_CFLAGS) \
> $(NULL)
>  libvirt_security_manager_la_LDFLAGS = $(AM_LDFLAGS)
> diff --git a/src/tpm/Makefile.inc.am b/src/tpm/Makefile.inc.am
> new file mode 100644
> index 00..1f5131bf34
> --- /dev/null
> +++ b/src/tpm/Makefile.inc.am
> @@ -0,0 +1,17 @@
> +# vim: filetype=automake
> +
> +TPM_UTIL_SOURCES = \
> +   tpm/virtpm.h \
> +   tpm/virtpm.c \
> +   $(NULL)
> +
> +
> +EXTRA_DIST += \
> +   $(TPM_UTIL_SOURCES) \
> +   $(NULL)
> +
> +noinst_LTLIBRARIES += libvirt_tpm.la
> +libvirt_la_BUILT_LIBADD += libvirt_tpm.la
> +libvirt_tpm_la_CFLAGS = $(AM_CFLAGS)
> +libvirt_tpm_la_LDFLAGS = $(AM_LDFLAGS)
> +libvirt_tpm_la_SOURCES = $(TPM_UTIL_SOURCES)
> diff --git a/src

Re: [libvirt] [PATCH 11/18] tpm: Refactor virTPMEmulatorInit to use loop

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Refactor virTPMEmulatorInit to use a loop with parameters. This allows
> for easier extension later on.
>
> Signed-off-by: Stefan Berger 

for the refactoring,
Reviewed-by: Marc-André Lureau 


> ---
>  src/tpm/virtpm.c | 80 ++--
>  1 file changed, 37 insertions(+), 43 deletions(-)
>
> diff --git a/src/tpm/virtpm.c b/src/tpm/virtpm.c
> index 4635d8add0..0179b1e8be 100644
> --- a/src/tpm/virtpm.c
> +++ b/src/tpm/virtpm.c
> @@ -113,51 +113,45 @@ virTPMGetSwtpmIoctl(void)
>  int
>  virTPMEmulatorInit(void)
>  {
> -if (!swtpm_path) {
> -swtpm_path = virFindFileInPath("swtpm");
> -if (!swtpm_path) {
> -virReportSystemError(ENOENT, "%s",
> - _("Unable to find 'swtpm' binary in 
> $PATH"));
> -return -1;
> +static const struct {
> +const char *name;
> +char **path;
> +} prgs[] = {
> +{
> +.name = "swtpm",
> +.path = _path,
> +},
> +{
> +.name = "swtpm_setup",
> +.path = _setup,
> +},
> +{
> +.name = "swtpm_ioctl",
> +.path = _ioctl,
>  }
> -if (!virFileIsExecutable(swtpm_path)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("TPM emulator %s is not an executable"),
> -   swtpm_path);
> -VIR_FREE(swtpm_path);
> -return -1;
> -}
> -}
> -
> -if (!swtpm_setup) {
> -swtpm_setup = virFindFileInPath("swtpm_setup");
> -if (!swtpm_setup) {
> -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -   _("Could not find 'swtpm_setup' in PATH"));
> -return -1;
> -}
> -if (!virFileIsExecutable(swtpm_setup)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("'%s' is not an executable"),
> -   swtpm_setup);
> -VIR_FREE(swtpm_setup);
> -return -1;
> -}
> -}
> +};
> +size_t i;
>
> -if (!swtpm_ioctl) {
> -swtpm_ioctl = virFindFileInPath("swtpm_ioctl");
> -if (!swtpm_ioctl) {
> -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> -   _("Could not find swtpm_ioctl in PATH"));
> -return -1;
> -}
> -if (!virFileIsExecutable(swtpm_ioctl)) {
> -virReportError(VIR_ERR_INTERNAL_ERROR,
> -   _("swtpm_ioctl program %s is not an executable"),
> -   swtpm_ioctl);
> -VIR_FREE(swtpm_ioctl);
> -return -1;
> +for (i = 0; i < ARRAY_CARDINALITY(prgs); i++) {
> +char *path;
> +bool findit = *prgs[i].path == NULL;
> +
> +if (findit) {
> +path = virFindFileInPath(prgs[i].name);
> +if (!path) {
> +virReportSystemError(ENOENT,
> +_("Unable to find '%s' binary in $PATH"),
> +prgs[i].name);
> +return -1;
> +}
> +if (!virFileIsExecutable(path)) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("%s is not an executable"),
> +   path);
> +VIR_FREE(path);
> +return -1;
> +}
> +*prgs[i].path = path;
>  }
>  }
>
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 08/18] tests: Add tests for QEMU command line generation with encrypted TPM

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> The QEMU command line does not change when TPM state is encrypted
> compared to when it is plain.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  .../tpm-emulator-tpm2-enc.x86_64-latest.args  | 35 +++
>  tests/qemuxml2argvtest.c  |  1 +
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.x86_64-latest.args
>
> diff --git a/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.x86_64-latest.args 
> b/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.x86_64-latest.args
> new file mode 100644
> index 00..3c8dc8e483
> --- /dev/null
> +++ b/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.x86_64-latest.args
> @@ -0,0 +1,35 @@
> +LC_ALL=C \
> +PATH=/bin \
> +HOME=/tmp/lib/domain--1-TPM-VM \
> +USER=test \
> +LOGNAME=test \
> +XDG_DATA_HOME=/tmp/lib/domain--1-TPM-VM/.local/share \
> +XDG_CACHE_HOME=/tmp/lib/domain--1-TPM-VM/.cache \
> +XDG_CONFIG_HOME=/tmp/lib/domain--1-TPM-VM/.config \
> +QEMU_AUDIO_DRV=none \
> +/usr/bin/qemu-system-x86_64 \
> +-name guest=TPM-VM,debug-threads=on \
> +-S \
> +-object secret,id=masterKey0,format=raw,\
> +file=/tmp/lib/domain--1-TPM-VM/master-key.aes \
> +-machine pc-i440fx-2.12,accel=tcg,usb=off,dump-guest-core=off \
> +-m 2048 \
> +-overcommit mem-lock=off \
> +-smp 1,sockets=1,cores=1,threads=1 \
> +-uuid 11d7cd22-da89-3094-6212-079a48a309a1 \
> +-display none \
> +-no-user-config \
> +-nodefaults \
> +-chardev socket,id=charmonitor,fd=1729,server,nowait \
> +-mon chardev=charmonitor,id=monitor,mode=control \
> +-rtc base=utc \
> +-no-shutdown \
> +-boot menu=on,strict=on \
> +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
> +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \
> +-chardev socket,id=chrtpm,path=/dev/test \
> +-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \
> +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 \
> +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\
> +resourcecontrol=deny \
> +-msg timestamp=on
> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
> index 91ca35d469..9c02cac8fc 100644
> --- a/tests/qemuxml2argvtest.c
> +++ b/tests/qemuxml2argvtest.c
> @@ -2082,6 +2082,7 @@ mymain(void)
>  QEMU_CAPS_DEVICE_TPM_PASSTHROUGH, 
> QEMU_CAPS_DEVICE_TPM_TIS);
>  DO_TEST_CAPS_LATEST("tpm-emulator");
>  DO_TEST_CAPS_LATEST("tpm-emulator-tpm2");
> +DO_TEST_CAPS_LATEST("tpm-emulator-tpm2-enc");
>
>  DO_TEST_PARSE_ERROR("pci-domain-invalid", NONE);
>  DO_TEST_PARSE_ERROR("pci-bus-invalid", NONE);
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 06/18] schema: Extend the TPM XML schema with support for encryption

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Extend the TPM XML schema with support for an encryption node.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  docs/schemas/domaincommon.rng | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 31db599ab9..4a4f4f8a4d 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -4316,6 +4316,7 @@
>
>   emulator
>
> +  
>  
>
>
> @@ -4345,6 +4346,35 @@
>  
>
>
> +  
> +
> +  
> +
> +  vtpm
> +
> +
> +  
> +
> +  
> +
> +  
> +
> +  
> +
> +  passphrase
> +
> +  
> +  
> +
> +  
> +
> +
> +  
> +
> +  
> +
> +  
> +
>
>  
>
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 07/18] tests: Add test for TPM XML encryption parser and formatter

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:25 PM Stefan Berger  wrote:
>
> Add a test case for the TPM XML encryption parser and formatter.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  .../tpm-emulator-tpm2-enc.xml | 34 +
>  .../tpm-emulator-tpm2-enc.xml | 38 +++
>  tests/qemuxml2xmltest.c   |  1 +
>  3 files changed, 73 insertions(+)
>  create mode 100644 tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.xml
>  create mode 100644 tests/qemuxml2xmloutdata/tpm-emulator-tpm2-enc.xml
>
> diff --git a/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.xml 
> b/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.xml
> new file mode 100644
> index 00..3838518e65
> --- /dev/null
> +++ b/tests/qemuxml2argvdata/tpm-emulator-tpm2-enc.xml
> @@ -0,0 +1,34 @@
> +
> +  TPM-VM
> +  11d7cd22-da89-3094-6212-079a48a309a1
> +  2097152
> +  512288
> +  1
> +  
> +hvm
> +
> +
> +  
> +  
> +
> +  
> +  
> +  destroy
> +  restart
> +  destroy
> +  
> +/usr/bin/qemu-system-x86_64
> +
> +
> +
> +
> +
> +  
> +
> +   uuid='32ee7e76-2178-47a1-ab7b-269e6e348015'/>
> +
> +  
> +
> +
> +  
> +
> diff --git a/tests/qemuxml2xmloutdata/tpm-emulator-tpm2-enc.xml 
> b/tests/qemuxml2xmloutdata/tpm-emulator-tpm2-enc.xml
> new file mode 100644
> index 00..7083fc9c13
> --- /dev/null
> +++ b/tests/qemuxml2xmloutdata/tpm-emulator-tpm2-enc.xml
> @@ -0,0 +1,38 @@
> +
> +  TPM-VM
> +  11d7cd22-da89-3094-6212-079a48a309a1
> +  2097152
> +  512288
> +  1
> +  
> +hvm
> +
> +
> +  
> +  
> +
> +  
> +  
> +  destroy
> +  restart
> +  destroy
> +  
> +/usr/bin/qemu-system-x86_64
> +
> +   function='0x2'/>
> +
> +
> +
> +
> +
> +  
> +
> +   uuid='32ee7e76-2178-47a1-ab7b-269e6e348015'/>
> +
> +  
> +
> +
> +   function='0x0'/>
> +
> +  
> +
> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
> index a29958ae29..f6cd56cc8f 100644
> --- a/tests/qemuxml2xmltest.c
> +++ b/tests/qemuxml2xmltest.c
> @@ -654,6 +654,7 @@ mymain(void)
>  DO_TEST("tpm-passthrough-crb", NONE);
>  DO_TEST("tpm-emulator", NONE);
>  DO_TEST("tpm-emulator-tpm2", NONE);
> +DO_TEST("tpm-emulator-tpm2-enc", NONE);
>
>  DO_TEST("metadata", NONE);
>  DO_TEST("metadata-duplicate", NONE);
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 04/18] util: Add VIR_STORAGE_ENCRYPTION_FORMAT_VTPM

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Add VIR_STORAGE_ENCRYPTION_FORMAT_VTPM with string 'vtpm' for
> support of encrypting vTPM storage.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  src/qemu/qemu_block.c   | 1 +
>  src/util/virstorageencryption.c | 2 +-
>  src/util/virstorageencryption.h | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
> index 0a6522577d..c3296c36f5 100644
> --- a/src/qemu/qemu_block.c
> +++ b/src/qemu/qemu_block.c
> @@ -1184,6 +1184,7 @@ 
> qemuBlockStorageSourceGetCryptoProps(virStorageSourcePtr src,
>  encformat = "luks";
>  break;
>
> +case VIR_STORAGE_ENCRYPTION_FORMAT_VTPM:
>  case VIR_STORAGE_ENCRYPTION_FORMAT_DEFAULT:
>  case VIR_STORAGE_ENCRYPTION_FORMAT_LAST:
>  default:
> diff --git a/src/util/virstorageencryption.c b/src/util/virstorageencryption.c
> index 49df7fddd8..4c7356d47a 100644
> --- a/src/util/virstorageencryption.c
> +++ b/src/util/virstorageencryption.c
> @@ -44,7 +44,7 @@ VIR_ENUM_IMPL(virStorageEncryptionSecret,
>
>  VIR_ENUM_IMPL(virStorageEncryptionFormat,
>VIR_STORAGE_ENCRYPTION_FORMAT_LAST,
> -  "default", "qcow", "luks",
> +  "default", "qcow", "luks", "vtpm",
>  );
>
>  static void
> diff --git a/src/util/virstorageencryption.h b/src/util/virstorageencryption.h
> index 3e5485d88b..29bd00056c 100644
> --- a/src/util/virstorageencryption.h
> +++ b/src/util/virstorageencryption.h
> @@ -59,6 +59,7 @@ typedef enum {
>  VIR_STORAGE_ENCRYPTION_FORMAT_DEFAULT = 0,
>  VIR_STORAGE_ENCRYPTION_FORMAT_QCOW, /* Both qcow and qcow2 */
>  VIR_STORAGE_ENCRYPTION_FORMAT_LUKS,
> +VIR_STORAGE_ENCRYPTION_FORMAT_VTPM,
>
>  VIR_STORAGE_ENCRYPTION_FORMAT_LAST,
>  } virStorageEncryptionFormatType;
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 03/18] tests: Add already existing test case tpm-emulator-tpm2

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Add an already existing test case tpm-emulator-tpm2 to qemuxml2xmltest.c
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  tests/qemuxml2xmltest.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
> index a64b17ac28..a29958ae29 100644
> --- a/tests/qemuxml2xmltest.c
> +++ b/tests/qemuxml2xmltest.c
> @@ -653,6 +653,7 @@ mymain(void)
>  DO_TEST("tpm-passthrough", NONE);
>  DO_TEST("tpm-passthrough-crb", NONE);
>  DO_TEST("tpm-emulator", NONE);
> +DO_TEST("tpm-emulator-tpm2", NONE);
>
>  DO_TEST("metadata", NONE);
>  DO_TEST("metadata-duplicate", NONE);
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 05/18] conf: Extend TPM XML parser with encryption support

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Extend the TPM device XML parser and XML generator with emulator
> state encryption support.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 


> ---
>  src/conf/domain_conf.c | 40 +++-
>  src/conf/domain_conf.h |  1 +
>  2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 3323c9a5b1..df6238c299 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -2950,6 +2950,7 @@ void virDomainTPMDefFree(virDomainTPMDefPtr def)
>  virDomainChrSourceDefClear(>data.emulator.source);
>  VIR_FREE(def->data.emulator.storagepath);
>  VIR_FREE(def->data.emulator.logfile);
> +virStorageEncryptionFree(def->data.emulator.encryption);
>  break;
>  case VIR_DOMAIN_TPM_TYPE_LAST:
>  break;
> @@ -13048,6 +13049,16 @@ virDomainSmartcardDefParseXML(virDomainXMLOptionPtr 
> xmlopt,
>   * 
>   *   
>   * 
> + *
> + * Emulator state encryption is supported with the following:
> + *
> + * 
> + *   
> + * 
> + * uuid='32ee7e76-2178-47a1-ab7b-269e6e348015'/>
> + * 
> + *   
> + * 
>   */
>  static virDomainTPMDefPtr
>  virDomainTPMDefParseXML(virDomainXMLOptionPtr xmlopt,
> @@ -13063,6 +13074,7 @@ virDomainTPMDefParseXML(virDomainXMLOptionPtr xmlopt,
>  VIR_AUTOFREE(char *) backend = NULL;
>  VIR_AUTOFREE(char *) version = NULL;
>  VIR_AUTOFREE(xmlNodePtr *) backends = NULL;
> +xmlNodePtr encnode = NULL;
>
>  if (VIR_ALLOC(def) < 0)
>  return NULL;
> @@ -13126,6 +13138,21 @@ virDomainTPMDefParseXML(virDomainXMLOptionPtr xmlopt,
>  def->data.passthrough.source.type = VIR_DOMAIN_CHR_TYPE_DEV;
>  break;
>  case VIR_DOMAIN_TPM_TYPE_EMULATOR:
> +encnode = virXPathNode("./backend/encryption", ctxt);
> +if (encnode) {
> +def->data.emulator.encryption =
> +   virStorageEncryptionParseNode(encnode, ctxt);
> +if (!def->data.emulator.encryption)
> +goto error;
> +if (def->data.emulator.encryption->format !=
> +VIR_STORAGE_ENCRYPTION_FORMAT_VTPM) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +   _("Unsupported vTPM encryption type '%s'"),
> +   virStorageEncryptionFormatTypeToString(
> +   def->data.emulator.encryption->format));
> +goto error;
> +}
> +}
>  break;
>  case VIR_DOMAIN_TPM_TYPE_LAST:
>  goto error;
> @@ -25949,8 +25976,19 @@ virDomainTPMDefFormat(virBufferPtr buf,
>  virBufferAddLit(buf, "\n");
>  break;
>  case VIR_DOMAIN_TPM_TYPE_EMULATOR:
> -virBufferAsprintf(buf, " version='%s'/>\n",
> +virBufferAsprintf(buf, " version='%s'",
>virDomainTPMVersionTypeToString(def->version));
> +if (def->data.emulator.encryption) {
> +virBufferAddLit(buf, ">\n");
> +virBufferAdjustIndent(buf, 2);
> +if (virStorageEncryptionFormat(buf,
> +   def->data.emulator.encryption) < 
> 0)
> +return -1;
> +virBufferAdjustIndent(buf, -2);
> +virBufferAddLit(buf, "\n");
> +} else {
> +virBufferAddLit(buf, "/>\n");
> +}
>  break;
>  case VIR_DOMAIN_TPM_TYPE_LAST:
>  break;
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index c1b5fc1337..a03986623a 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -1270,6 +1270,7 @@ struct _virDomainTPMDef {
>  virDomainChrSourceDef source;
>  char *storagepath;
>  char *logfile;
> +virStorageEncryptionPtr encryption;
>  } emulator;
>  } data;
>  };
> --
> 2.20.1
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 02/18] tests: Add test for new Secret vTPM usage type

[Marc-André Lureau]

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Extend the schema for the Secret to support the vTPM usage type
> and add a test case for parsing the Secret with usage type vTPM.
>
> Signed-off-by: Stefan Berger 
> ---
>  docs/schemas/secret.rng  | 10 ++
>  tests/secretxml2xmlin/usage-vtpm.xml |  7 +++
>  tests/secretxml2xmltest.c|  1 +
>  3 files changed, 18 insertions(+)
>  create mode 100644 tests/secretxml2xmlin/usage-vtpm.xml
>
> diff --git a/docs/schemas/secret.rng b/docs/schemas/secret.rng
> index 1e94d66e48..e0add8a5e9 100644
> --- a/docs/schemas/secret.rng
> +++ b/docs/schemas/secret.rng
> @@ -37,6 +37,7 @@
>
>
>
> +  
>
>  
>
> @@ -81,4 +82,13 @@
>  
>
>
> +  
> +
> +  vtpm
> +
> +
> +  
> +
> +  
> +
>  

should be in previous patch

> diff --git a/tests/secretxml2xmlin/usage-vtpm.xml 
> b/tests/secretxml2xmlin/usage-vtpm.xml
> new file mode 100644
> index 00..5baff3034d
> --- /dev/null
> +++ b/tests/secretxml2xmlin/usage-vtpm.xml
> @@ -0,0 +1,7 @@
> +
> +  aa6c7af2-45a7-477c-85a2-fe86d9f2514e
> +  vTPM secret
> +  
> +vTPMvTPMvTPM
> +  
> +
> diff --git a/tests/secretxml2xmltest.c b/tests/secretxml2xmltest.c
> index fd93703424..595583346a 100644
> --- a/tests/secretxml2xmltest.c
> +++ b/tests/secretxml2xmltest.c
> @@ -80,6 +80,7 @@ mymain(void)
>  DO_TEST("usage-ceph");
>  DO_TEST("usage-iscsi");
>  DO_TEST("usage-tls");
> +DO_TEST("usage-vtpm");
>
>  return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
>  }
> --
> 2.20.1
>

other than that,
Reviewed-by: Marc-André Lureau 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 01/18] secret: Add support for usage type vTPM

[Marc-André Lureau]

Hi

On Tue, Jul 9, 2019 at 9:24 PM Stefan Berger  wrote:
>
> Add support for usage type vTPM to secret.
>
> Signed-off-by: Stefan Berger 
> ---
>  include/libvirt/libvirt-secret.h |  1 +
>  src/conf/secret_conf.c   | 13 +
>  src/util/virsecret.c |  2 +-
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/include/libvirt/libvirt-secret.h 
> b/include/libvirt/libvirt-secret.h
> index 9a1065f0f3..e5aaac9450 100644
> --- a/include/libvirt/libvirt-secret.h
> +++ b/include/libvirt/libvirt-secret.h
> @@ -43,6 +43,7 @@ typedef enum {
>  VIR_SECRET_USAGE_TYPE_CEPH = 2,
>  VIR_SECRET_USAGE_TYPE_ISCSI = 3,
>  VIR_SECRET_USAGE_TYPE_TLS = 4,
> +VIR_SECRET_USAGE_TYPE_VTPM = 5,
>
>  # ifdef VIR_ENUM_SENTINELS
>  VIR_SECRET_USAGE_TYPE_LAST
> diff --git a/src/conf/secret_conf.c b/src/conf/secret_conf.c
> index 5b85a7c0be..b291339e77 100644
> --- a/src/conf/secret_conf.c
> +++ b/src/conf/secret_conf.c
> @@ -110,6 +110,15 @@ virSecretDefParseUsage(xmlXPathContextPtr ctxt,
>  }
>  break;
>
> +case VIR_SECRET_USAGE_TYPE_VTPM:
> +def->usage_id = virXPathString("string(./usage/name)", ctxt);
> +if (!def->usage_id) {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +   _("vTPM usage specified, but name is missing"));
> +return -1;
> +}
> +break;
> +
>  default:
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> _("unexpected secret usage type %d"),
> @@ -257,6 +266,10 @@ virSecretDefFormatUsage(virBufferPtr buf,
>  virBufferEscapeString(buf, "%s\n", def->usage_id);
>  break;
>
> +case VIR_SECRET_USAGE_TYPE_VTPM:
> +virBufferEscapeString(buf, "%s\n", def->usage_id);
> +break;
> +
>  default:
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> _("unexpected secret usage type %d"),
> diff --git a/src/util/virsecret.c b/src/util/virsecret.c
> index 854dc72b06..7844a76a56 100644
> --- a/src/util/virsecret.c
> +++ b/src/util/virsecret.c
> @@ -34,7 +34,7 @@ VIR_LOG_INIT("util.secret");
>
>  VIR_ENUM_IMPL(virSecretUsage,
>VIR_SECRET_USAGE_TYPE_LAST,
> -      "none", "volume", "ceph", "iscsi", "tls",
> +  "none", "volume", "ceph", "iscsi", "tls", "vtpm",
>  );
>
>  void
> --
> 2.20.1
>

Looks good, but docs/schemas/secret.rng change should probably be part
of this patch.

other than that,
Reviewed-by: Marc-André Lureau 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] RFC: use a slirp helper process

[Marc-André Lureau]

Hi

On Tue, Apr 30, 2019 at 7:31 PM Daniel P. Berrangé  wrote:
> > At this point, the slirp-helper doesn't handle migration. But is it
> > really worth it? From a guest POV, it would look like packet lost or
> > disconnection. Adding migration handling is possible, to avoid a
> > disconnection event. How should it be done? via a libvirt provided
> > socket for storage? via its own file transferred by libvirt? via qemu
> > somehow (qemu wouldn't really know about the external process but
> > would copy around the migration bits?).
>
> How does migration actually work today with built-in slirp ? I

It is registered with save_state/load_state callbacks (old-style
vmstate), and save/load from the given stream.

It uses the "vmstate format" so far, although it could be a blob for
what qemu is concerned (there is no json-desc, although there could
be, but that would make libslirp even more relying on vmstate format).

But the interesting thing is that very few state is saved. Beside some
DHCP (bootp) state, only guestfwd sockets are saved. I suppose the
reason is that it's not "possible" to migrate a system socket. On
destination, UDP sockets will be handled by guest OS fine, new slirp
UDP socket will be created, and guest will mostly see some packet
lost. For TCP, in general, there isn't anything slirp can really do.
Even if slirp did attempt to save/restore TCP sockets, this will
result in stream corruption (or just disconnection) in the guest.

That's why it probably doesn't make much sense to save much of slirp
socket state beside guestfwd, and let the guest handle socket
disconnect/reconnect.

> Assume that all open network connections are lost right now ?

So guestfwd (& udp) sockets shouldn't be "lost" from guest POV. But
TCP sockets will be.

>
> What actual state does QEMU transfer for built-in slirp what
> does that achieve in practice ?
>
> Ideally we would "live migrate" all existing QEMU processes using
> built-in slirp to use the slirp helper.  Even if this doesn't
> actually do much useful stuff due to all connections being lost,
> it allows us to automatically enable external  slirp for everything
> out of the box. Requiring an opt-in config for external slirp makes
> it less compelling & will massively reduce uptake.

It's not reasonable to expect built-in slirp VM to migrate to external
slirp imho. Qemu doesn't know much about the external helper, it talks
ethernet frame with it only.

When external slirp process learns migration support, either libvirt
manages the "state" (read it, transfer it etc), or we could somehow
teach qemu to do it, ex "-savevm-external chardev", which would talk a
simple protocol to read/save the state.

Other ideas? thanks


-- 
Marc-André Lureau

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] RFC: use a slirp helper process

[Marc-André Lureau]

Hi

On Thu, Apr 25, 2019 at 3:22 PM Michal Privoznik  wrote:
>
> On 4/18/19 3:24 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > I am throwing this away for discussions, and early feedback.
> >
> > With the upcoming release of libslirp[1], we have an opportunity to
> > run SLIRP networking in a separate process. This will allow for
> > stricter security policies for both qemu & slirp, as slirp is
> > notoriously not very safe (discussed on ML, various CVEs, and even the
> > code says so explicitly in the comments), yet people rely on it regularly.
>
> Do they? I mean, SLIRP is broken in libvirt for quite some time and we
> haven't noticed nor seen a bug about it. What is the typical use anyway?

"user" networking () is not broken, it's
guestfwd that is not working for a while apparently.

Various projects use slirp forks, that's why we decided to make it
again a standalone project / library that can be shared. slirp4netns
(used by podman afaik), is perhaps the most worrisome to me.


> I can see some potential in combining -netdev user + -chardev where one
> could see/inject packets into a guest (if I got that correctly). But
> that can't work currently, because libvirt doesn't allow setting all the
> interesting bits (like subnet mask).
>
> >
> > For network type "user", libvirt could spawn an helper process (an
> > experimental version is [2]). It would setup a socket pair between
> > qemu and the helper and use -net socket. qemu could then be built
> > without libslirp! (imho, qemu should deprecate built-in -net user
> > support, and doesn't need to grow its own sub-process handling)
> >
> > This libvirt patch is a bit rough, I am not sure where things should
> > go. In particular, how to manage the subprocesses properly (security
> > aspects, and lifecycle etc), and how to deal with migration (prevent
> > migrating from non-helper to helper version etc).
> >
> > It seems guestfwd has been non-functional for a while. This is also
> > something that the current experimental helper doesn't support
> > atm. Doing all the various "channel" types that libvirt/qemu support
> > would be tedious, and probably unnecessary. But the underlying
> > libslirp library support redirections the same way qemu does today, so
> > it could be added if necessary.
> >
> > At this point, the slirp-helper doesn't handle migration. But is it
> > really worth it? From a guest POV, it would look like packet lost or
> > disconnection. Adding migration handling is possible, to avoid a
> > disconnection event. How should it be done? via a libvirt provided
> > socket for storage? via its own file transferred by libvirt? via qemu
> > somehow (qemu wouldn't really know about the external process but
> > would copy around the migration bits?).
> >
> > Does the helper need to have a "standard" & capabilities, similar to
> > what is proposed for vhost-user [3]? This would allow for easier
> > competing implementation to emerge (I have plans in mind, not using
> > libslirp).
> >
> > Thanks for the feedback!
> >
> > [1] https://gitlab.freedesktop.org/slirp/libslirp
> > [2] https://github.com/elmarco/libslirp-rs
> > [3] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/vhost-user.json
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   m4/virt-driver-qemu.m4 |  5 ++
> >   src/qemu/libvirtd_qemu.aug |  1 +
> >   src/qemu/qemu.conf |  3 ++
> >   src/qemu/qemu_capabilities.c   |  6 +++
> >   src/qemu/qemu_capabilities.h   |  1 +
> >   src/qemu/qemu_command.c| 38 +++---
> >   src/qemu/qemu_command.h|  3 +-
> >   src/qemu/qemu_conf.c   |  7 ++-
> >   src/qemu/qemu_conf.h   |  1 +
> >   src/qemu/qemu_domain.c | 11 
> >   src/qemu/qemu_domain.h |  3 ++
> >   src/qemu/qemu_hotplug.c|  5 +-
> >   src/qemu/qemu_interface.c  | 80 ++
> >   src/qemu/qemu_interface.h  |  6 +++
> >   src/qemu/test_libvirtd_qemu.aug.in |  1 +
> >   15 files changed, 161 insertions(+), 10 deletions(-)
>
> The code looks more or less okaysh, but I'd rather discuss the future of
> slirp for now.
>

Well, that's what I propose to discuss with this proposal. Make
current libslirp usage safer by using it as a subprocess, continue to
improve/fix it, and allow competing implementation to emerge.

thanks for the feedback

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list