[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate
Date: Wed, 10 Jul 2019 10:53:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 08/07/19 18:04, Daniel P. Berrangé wrote:
> The downside of using the bus daemon is that we have to spawn a new
> instance of dbus-daemon for every QEMU VM that's running on the host,
> which is yet more memory overhead for each VM & another process to
> manage, and yet another thing to go wrong.
> QEMU already has a direct UNIX socket connection to the helper
> processes in question. I'd much rather we just had another direct
> UNIX socket  connection to that helper, using D-Bus peer-to-peer.
> The benefit of debugging doesn't feel compelling enough to justify
> running an extra daemon for each VM.

Would it be possible to make QEMU the broker?  That is, how hard would it
be to embed a minimal DBus broker (which only takes care of connecting servers
and clients---stuff like launching servers would be completely out of scope)?

Would it for example make sense to split the bus handling part of dbus-broker
into a library that QEMU could reuse?  (And if we plan to do this, should QEMU
use sd-bus instead of gdbus?)

In QOM that would be something like

  -object dbus-connection,id=client1,chardev=...,addr=foo       # p2p
  -object dbus-vmstate,connection=client1                       # the interface

  -object dbus-connection,id=client1,addr=foo                   # via external 
  -object dbus-vmstate,client=client1                           # the interface

  -object dbus-session,id=session1,chardev=...
  -object dbus-connection,id=client1,session=session1,addr=foo  # via internal 
  -object dbus-vmstate,client=client1                           # the interface


reply via email to

[Prev in Thread] Current Thread [Next in Thread]