This old test was added by me to allow people to keep the spicevmc
channel while changing graphics type from spice to something else.
However we do not do this in other places and also now we have all the
Validate functions so it is better to show the user they will not have
the spicevmc channel available rather than simply not formatting it on
the qemu command line.
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>
Notable schema changes:
- 'cluster-id' is now reported for CPU topology
- 'display-update' QMP command added
- 'main-loop' QOM object added with a whole set of properties
- 'cpu0-id' field reported in SEV data
- 'blockdev-change-medium' command now has 'force' property
- 'screendump' QMP command now has a 'format' property
- supported formats are 'ppm' and 'png'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@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>
There are no major changes since 7.0.0-rc2, but a few additional
features are enabled in this build.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The parameters of self.warning is inconsistent with its definition, So
fix it.
Signed-off-by: luzhipeng <luzhipeng@cestc.cn>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Currently translated at 22.8% (2385 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>
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>
Checking the signature in two different places makes no sense since the
code in between can only mark the candidate as the best option so far,
which is what the second signature match does as well.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These ancient RHEL-only CPU models should not really be used by any CPU
definition created by libvirt. We keep them just for backwards
compatibility with domains which might still be using them.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
in preparation for the addition of DomainRestoreParams,
add it to the list of methods requiring a conn first argument.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
add new API in order to be able to extend parameters to the domain
restore operation. We will use it to fit the existing arguments of
VirDomainRestoreFlags for now.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
create an alternative to virDomainSaveFlags that is more
extendible via parameters.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
where it can be reused by other helpers.
No changes other than the move.
Note that this makes iohelper now dependent on -lutil and -lacl.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Claudio Fontana <cfontana@suse.de>
this is in preparation for a minor refactoring of the copy
function itself out of runIO().
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Using an updated toolchain means we're likely to catch more
issues.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As of 47503cc859 we are statically linking libtest_utils_qemu.a
into qemuhotplugmock.so (see the original commit for reasoning).
However, this breaks ASAN on older clang because now
qemuhotplugtest has two instances of virCPUDef global variables
(cpuDefault, cpuHaswell, cpuPower8, cpuPower9). One that comes
from the binary itself (which also links with
libtest_utils_qemu.a) and the other from the mock. Resolve this
by making the variables static and introducing getter and setter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
As of 47503cc859 we are statically linking libtest_utils.a into
qemuhotplugmock.so (see the original commit for reasoning).
However, this breaks ASAN on older clang because now
qemuhotplugtest has two instances of virTestHostArch global
variable. One that comes from the binary itself (which also links
with libtest_utils.a) and the other from the mock. Resolve this
by making the variable static and introducing getter and setter.
Well, the former already exists (as virArchFromHost()) so only
the latter is needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Notable changes:
* use the most recent point release for FreeBSD 12.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was originally introduced in c2fb8bfee3, reportedly to
support symbol versioning on Solaris; more recently, 30b301c6ea
ported it to meson.
Up until the previous commit this has resulted in passing
-M .../libvirt/build/src/libvirt.syms
to the linker on macOS, but the implementation of the -M option
on that platform's linker is literally
else if ( strcmp(arg, "-M") == 0 ) {
// FIX FIX
}
so in practice we've been providing an additional input file,
which the linker understandably ignores after printing a warning
since it's not in any format that it recognizes.
Considering that LLVM's linker, which is now used by default on
FreeBSD, supports the same --version-script option as the GNU
linker, that we have introduced special handling for macOS, and
that we don't target Solaris, we can simply drop the branch at
this point.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
macOS libraries don't support symbol versioning, so the only
result that we achieve by passing additional flags to the linker
is a bunch of messages like
ld: warning: ignoring file .../libvirt/build/src/libvirt.syms,
building for macOS-x86_64 but attempting to link with file built
for unknown-unsupported file format ( 0x23 0x20 0x57 0x41 ... )
being produced during the build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This ensures variable names and the overall structure of the
code setting and using them is consistent. It will also make
upcoming changes less disruptive.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When constructing mock_libs array it is firstly initialized to a
static set of mocks followed by couple of WITH_* checks to append
driver specific mocks. These checks are then repeated when
filling some other variables (e.g. supplementary helpers,
libraries, tests, etc.). Dissolve the former in the latter since
we are already doing that, partially, for qemu (qemucapsprobemock
and qemuhotplugmock)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As of ad81aa8ad0 the qemuhotplugmock.c calls
testQemuPrepareHostBackendChardevOne() which is implemented in
testutilsqemu.c. However, the mock is not linked with
testutilsqemu static library which makes some tools (valgrind
particularly) unhappy because the resulting mock library has
unresolved symbol.
The fix is simple, link mock library with test_utils_qemu_lib and
also with test_utils_lib since testutils.c calls some functions
from testutils.c.
Since these two libraries are declared only after mock_libs[], I
had to move the line that declares qemuhotplugmock after those
two.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
