[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
daemon
-object dbus-vmstate,client=client1 # the interface
-object dbus-session,id=session1,chardev=...
-object dbus-connection,id=client1,session=session1,addr=foo # via internal
daemon
-object dbus-vmstate,client=client1 # the interface
Paolo
- Re: [Qemu-devel] [PATCH 3/3] Add dbus-vmstate object, (continued)
- Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate,
Paolo Bonzini <=