Use the new infrastructure which stores the fds inside 'qemuFDPass'
objects in the private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All callers now pass NULL/0 as arguments for vhostfd passing so we can
remove all the associated code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now all the helper variables and code are not needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new infrastructure which stores the fds inside 'qemuFDPass'
objects in the private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the linebreaks inside of error messages.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All callers effectively pass 'net->driver.virtio.queues'. In case of the
code in 'qemu_hotplug.c' this value was set to '1' if it was 0 before.
Since 'qemuBuildNicDevProps' only uses it if it's greater than 1 we can
remove all the extra complexity.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add alternative code paths for passing of the FDs using the new
infrastructure. This way we'll be able to refactor the code
incrementally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After the 'qemuFDPass' code was refactored we no longer need to hand off
the FD to qemu before we know the path for it.
Thus the call to qemuBuildHostNetProps can be moved outside of the
monitor critical section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pre-construct the array the same way for the case when there's only one
FD and when there are multiple. We just change the argument name
depending on the count.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the block guarded by 'is_tap' boolean to the only place where
'is_tap' is set to true.
This causes few arguments to change places.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the setup of the 'vdpa' netdev into the new helper shared between
commandline and hotplug code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The helper will aggregate code that is used to connect the network
backend to the corresponding host portion.
This will be used to refactor the duplicated code between the cold-start
and hotplug helper functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare for the upcoming refactor to use qemuFDPass for all the network
related file descriptors:
- tapfds
- vhostfds
- slirp
- vdpa
This patch adds the private data variables and a utility function to
clear it. Clearing is useful since we don't really need the data once
the VM is running so we save some memory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the FDs are closed right after use to prevent leaks, at certain
point we don't need the whole helper any more. Clear them for char
devices after hotplug and on start.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We don't want to keep the FDs open more than we need to.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only caller doesn't use the fdset info any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we use our own fdset ID when hot-adding a fdset we can vastly
simplify our internals.
As a stop-gap when a fdset would be added behind libvirt's back we'll
validated that the fdset to be added is not yet used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'add-fd' qmp command gives the possibility to find an unused fdset
ID when hot-adding fdsets, such usage is extremely inconvenient.
This patch allows us to track the used fdset id so that we can avoid the
need to check results and thus employ simpler code flow when hot-adding
devices which use FD passing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code didn't check that the reply value is an array and that the
'fds' array is present. This could lead to a crash if qemu wouldn't
return an array in those places.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt doesn't use the returned value and in fact there's nothing we
could even do with them. Avoid parsing and storing them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We use the qemuFDPass infrastructure when building the command line,
refactor the monitor too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's effectively replaced by checks in qemuFDPassTransfer. This will
simplify cleanup paths on constructing the qemuFDPass object when FDs
are being handled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add validation to the transfer step to make the adding step more simple
for easier cleanup paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add possibility to delay checks to the point when the FDs are to be
passed to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Calling virDomainRestoreFlags() with no typed params results in
an error in open() because it tries to open a NULL path.
Obviously, this is wrong and path to restore from must be
provided, at least for now until other sources of restore are
introduced. Then this limitation can be relaxed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When no VIR_DOMAIN_SAVE_PARAM_FILE typed param is set when
calling virDomainSaveParams() then in turn virQEMUFileOpenAs()
tries to open a NULL path.
We have two options now:
1) require the typed param, which in turn may be promoted to a
regular argument, or
2) use this opportunity to make the API behave like
virDomainManagedSave() and use typed params to pass extra
arguments, instead of having to invent new managed save API
with typed params.
Let's go with option 2, as it is more future proof.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The code that actually does managed save within
qemuDomainManagedSave() is going to be reused shortly. Move it
out into a separate helper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The qemuDomainManagedSavePath() function does no more than a
g_strdup_printf() and as such can't return NULL really.
Therefore, don't check for its return value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Every running QEMU process we are willing to reconnect (i.e., at least
3.1.0) supports migration events and we can assume the capability is
already enabled since last time libvirt daemon connected to its monitor.
Well, it's not guaranteed though. If libvirt 1.2.17 or older was used to
start QEMU 3.1.0 or newer, migration events would not be enabled. And if
the user decides to upgrade libvirt from 1.2.17 to 8.4.0 while the QEMU
process is still running, they would not be able to migrate the domain
because of disabled migration events. I think we do not really need to
worry about this scenario as libvirt 1.2.17 is 7 years old while QEMU
3.1.0 was released only 3.5 years ago. Thus a chance someone would be
running such configuration should be fairly small and a combination with
upgrading 1.2.17 to 8.4.0 (or newer) with running domains should get it
pretty much to zero. The issue would disappear ff the ancient libvirt is
first upgraded to something older than 8.4.0 and then to the current
libvirt.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
All QEMU versions we care about support migration events and we should
be able to enable the associated capability when connecting to the
monitor. Failure to do so is thus considered fatal now.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The code was a bit too complicated, especially after removing the check
for QEMU_CAPS_MIGRATION_EVENT.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
All QEMU versions we care about already support migration events.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A few commits ago new APIs were introduced (virDomainSaveParams()
and virDomainRestoreParams()) and with them new typed parameters:
VIR_SAVE_PARAM_FILE and VIR_SAVE_PARAM_DXML. But their name does
not suggest they apply to either of the APIs nor that they are
intended for domain related APIs. Switch to
VIR_DOMAIN_SAVE_PARAM prefix to make it obvious.
It's true we already have VIR_DOMAIN_SAVE_* symbols which are
part of virDomainSaveRestoreFlags enum, therefore stick also with
'_PARAM_ ' part of the name to differentiate the two.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For most of them qemu errors out with unclear message, and for the
audiodev qemu just falls back to timer-based audio with a warning
message, and will possibly also error out in the future.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035163
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After previous cleanup the 'error' label in
qemuDomainObjPrivateXMLParse() contains nothing but a return
statement. Well, the label can be dropped and all 'goto'-s can be
replaced with the return statement directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuDomainObjPrivateXMLParse() is responsible for parsing
given XML into qemuDomainObjPrivate struct. As it does so, memory
might be allocated for some members. If an error occurs during
parsing the control jumps onto 'error' label where only some of
previously allocated memory is freed. The reason there's no
memory leak is simple: the only caller (virDomainObjParseXML())
unrefs freshly created virDomainObj which in turn causes
qemuDomainObjPrivateFree() to be called. Therefore, these
partial, selective frees are needless and should be just dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that qemuDomainObjPrivate struct gained new member format it
into XML and parse it so that the value is preserved across
daemon restarts.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since v1.3.0-90-gafbe1d4c56 the original value of memlock limit
is stored inside virDomainObj struct directly (under
originalMemlock member). This is needless because the value is
used only inside QEMU driver and thus can reside in
qemuDomainObjPrivate struct.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
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:
<channel type='qemu-vdagent'>
<target type='virtio' name='com.redhat.spice.0'/>
<source>
<clipboard copypaste='yes'/>
<mouse mode='client'/>
</source>
</channel>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This enumeration will be useful for vnc with the upcoming qemu-vdagent
device so make the name more generic.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Detect whether qemu supports the qemu-vdagent character device. This
enables support for copy/paste with VNC graphics.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There's no real difference between
qemuSecurityStartVhostUserGPU() and qemuSecurityCommandRun(). The
latter is used more frequently while the former has just one
user. Therefore, drop the less frequently used one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It allows libvirt to provide the value of cpu0-id retuned by the Qemu QMP
command query-sev-capabilities as implemented by the Qemu Patch [1] which
is merged to Qemu master branch and should be available with Qemu 7.1.
This is used to get the signed Chip Endorsement Key (CEK) of the CPU of AMD
system from AMD's Key Distribution Service (KDS).
Similar to cbitpos, reducedPhysBits, maxGuests & maxESGuests;
the value of cpu0-id is also provided using 'virsh domcapability'.
[1] https://lore.kernel.org/all/20220228093014.882288-1-dovmurik@linux.ibm.com/
Signed-off-by: Niteesh Dubey <niteesh@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We do not need VIR_DOMAIN_VIRT_QEMU to get qemu default
version. With the 'os_type' and 'arch'in capabilities,
we could identify 'emulator' which is enough to get the version.
Actually VIR_DOMAIN_VIRT_QEMU is not the only domain virt type for
qemu driver, there are VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF.
If TCG is disabled in qemu, it will cause the error that could not
find suitable emulater when access version.
Signed-off-by: Liang Yan <lyan@digtalocean.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
