If the port allocator bitmap does not have enough bits to keep the state
of the port we're going to release, the port is not reserved and thus is
trivially released without doing anything. No need to report an error in
such case.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The USB device redirection works in a similar way as Spice. The
underlying 'dbus' channel is set to "org.qemu.usbredir" by default for
the client to identify the channel purpose (as specified in -display
dbus documentation).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Like a Spice port, a dbus serial must specify an associated channel name.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This implementation reports only Unix bus address using the URI format
proposed in https://gitlab.freedesktop.org/dbus/dbus/-/issues/348.
We prefer a URI form over the D-Bus address form, since all other
display protocols use a URI, allowing to distinguish between protocols
and making client implementation simpler.
Other transports (for example TCP) are not yet handled.
The client is assumed to know what to lookup on the bus (the bus name,
path & interface of the VM, eventually matching its UUID)
P2P mode doesn't report any available URI.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
By default, libvirt will start a private bus and tell QEMU to connect to
it. Instead, a D-Bus "address" to connect to can be specified, or the
p2p mode enabled.
D-Bus display works best with GL & a rendernode, which can be specified
with <gl> child element.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Start the daemon if necessary (it is already stopped in qemuProcessStop)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The remoteOpenConn() function was refactored recently. As a part
of that new variable @newconn was introduced which holds
virConnect object as it's being gradually constructed throughout
the function. At the very end, when everything succeeded the
variable is stolen into passed @conn. However, there was one
line missed in the refactor which still access the @conn instead
of @newconn leading to a NULL dereference.
Fixes: f7c422993e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Use a temporary variable 'newconn' to hold the newly opened connection
until we are ready to pass it back instead of the original connection.
This way we can avoid complicated 'error'/'cleanup' sections.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Refactor the code to use virTypedParamList which simplifies cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'identparams' typed parameter list obtained from
virIdentityGetParameters is leaked when called from
'virGetConnectGeneric'.
Use 'virTypedParamListFromParams' to absorb it into a virTypedParamList
which can be autofreed.
Note that the memleak is observable only when running in split-daemon
mode.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/314
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The helper constructs a virTypedParamList from loose params.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Currently translated at 22.9% (2386 of 10419 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
Remove the argument from the function prototypes and the callback
handler.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The returned value is used to unlock the object, so all callers must
necessarily make use of the returned value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
