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>
It will be used in future patch in multiple places.
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>
Validate the domain configuration to ensure that if there are more than
one vgpu assigned to a domain, only one of them has 'ramfb' enabled.
This was never a supported configuration. QEMU failed confusingly when
attempting to start a domain with this configuration. This change
attempts to provide better information about the error.
https://bugzilla.redhat.com/show_bug.cgi?id=2079760
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@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>
While we don't want to aim for the shortest list of disabled features in
the baseline result (it would select a very old model), we want to do so
while looking at any of the input models for which we're trying to
compute a baseline CPU model. Given a set of input models, we always
want to take the least capable one of them (i.e., the one with shortest
list of disabled features) or a better model which is not one of the
input models.
So when considering an input model, we just check whether its list of
disabled features is shorter than the currently best one. When looking
at other models we check both enabled and disabled features while
penalizing disabled features as implemented by the previous patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For finding the best matching CPU model for a given set of features
while we don't know the CPU signature (i.e., when computing a baseline
CPU model) we've been using a "shortest list of features" heuristics.
This works well if new CPU models are supersets of older models, but
that's not always the case. As a result it may actually select a new CPU
model as a baseline while removing some features from it to make it
compatible with older models. This is in general worse than using an old
CPU model with a bunch of added features as a guest OS or apps may crash
when using features that were disabled.
On the other hand we don't want to end up with a very old model which
would guarantee no disabled features as it could stop a guest OS or apps
from using some features provided by the CPU because they would not
expect them on such an old CPU.
This patch changes the heuristics to something in between. Enabled and
disabled features are counted separately so that a CPU model requiring
some features to be disabled looks worse than a model with fewer
disabled features even if its complete list of features is longer. The
penalty given for each additional disabled feature gets bigger to make
longer list of disabled features look even worse.
https://bugzilla.redhat.com/show_bug.cgi?id=1851227
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It will become more complicated and so it deserves to be separated into
a new function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
