Add an element to configure the thread pool size:
...
<binary>
<thread_pool size='16'/>
</binary>
...
https://bugzilla.redhat.com/show_bug.cgi?id=2072905
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As of v7.0.0-877-g70ac26b9e5 QEMU exposes its default event loop
for devices with no IOThread assigned as an QMP object. In the
very next commit (v7.0.0-878-g71ad4713cc) it was extended for
thread-pool-min and thread-pool-max attributes. Expose them under
new <defaultiothread/> element.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability reflects whether QEMU allows setting
thread-pool-min and thread-pool-max attributes on iothread
object. Since both attributes were introduced in the same commit
(v7.0.0-878-g71ad4713cc) and can't exist independently of each
other we can stick with one capability covering both of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
At least in case of QEMU an IOThread is actually a pool of
threads (see iothread_set_aio_context_params() in QEMU's code
base). As such, it can have minimal and maximal number of worker
threads. Allow setting them in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This command tells QEMU to start listening for an incoming post-copy
recovery connection. Just like migrate-incoming is used for starting
fresh migration on the destination host.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jobs that are supposed to remain active even when libvirt daemon
restarts were reported as started at the time the daemon was restarted.
This is not very helpful, we should restore the original timestamp.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Notable changes:
- Icelake-Client cpu model family removed:
"Icelake-Client-noTSX-x86_64-cpu"
"Icelake-Client-v1-x86_64-cpu"
"Icelake-Client-v2-x86_64-cpu"
"Icelake-Client-v3-x86_64-cpu"
"Icelake-Client-x86_64-cpu"
- 'zero-copy-send' migration feature added
- display 'sdl' qapified
- 'arch-lbr' cpu feature added
- new HyperV enlightenments:
'hv-tlbflush-ext'
'hv-tlbflush-direct'
'hv-emsr-bitmap'
'hv-xmm-input'
- 'none-machine' has two new properties:
- "boot" described as "Boot configuration"
- "memory" described as "Memory size configuration"
- 'igd-passthrough-isa-bridge' is now Xen-only
- CXL: Compute eXpress Link related devices:
"CXL"
"cxl-rp",
"cxl-type3",
"pxb-cxl",
"pxb-cxl-bus",
"pxb-cxl-host",
- 'dma-translation' feature of 'intel-iommu'
- 'vmcb-clean' cpu feature now migratable:
- possibly due to host kernel upgrade
- changes commandline generated for the 'cpu-host-model' case of
qemuxml2argvtest
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We already allow users to provide TFTP root path in network XML
and not specify any DHCP. This makes sense, because dnsmasq is
not only DHCP server but also TFTP server and users might have
a DHCP server configured on their own, outside of libvirt's
control and want just the TFTP part.
By moving TFTP config generator out of DHCP generator and calling
it for every IPv4 range, users can finally enable just TFTP.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026765
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainObj struct has @pid member where the domain's
hypervisor PID is stored (e.g. QEMU/bhyve/libvirt_lxc/... PID).
However, we are not consistent when it comes to shutoff state.
Initially, because virDomainObjNew() uses g_new0() the @pid is
initialized to 0. But when domain is shut off, some functions set
it to -1 (virBhyveProcessStop, virCHProcessStop, qemuProcessStop,
..).
In other places, the @pid is tested to be 0, on some other places
it's tested for being negative and in the rest for being
positive.
To solve this inconsistency we can stick with either value, -1 or
0. I've chosen the latter as it's safer IMO. For instance if by
mistake we'd kill(vm->pid, SIGTERM) we would kill ourselves
instead of init's process group.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
There are some tools that convert hostname to lowercase before
resolving it (e.g. ssh). In a way it makes sense because DNS is
case insensitive and in case of ssh the lowercase version is then
used to find matching record in its config file. However, our NSS
module performs case sensitive comparison, which makes it useless
with ssh. Just consider a machine named FooBar.
Therefore, switch to case insensitive string comparison.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1777873
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Add POWER10 as a supported cpu model.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Use the newly added ARG_CAPS_HOST_CPU_MODEL to set which host CPU we
expect the test to use - the test should fail when using a POWER8 host
cpu but complete when using a POWER9 host cpu.
Two new macros were added because we will be adding similar tests in the
near future when adding support for the Power10 chip.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
When loading a latest caps for an arch for the first time the following
occurs in testQemuInfoInitArgs():
- the caps file is located. It's not in the cache since it's the first time
it's being read;
- the cachecaps are retrieved using qemuTestParseCapabilitiesArch() and
stored in the capscache;
- FLAG_REAL_CAPS is set and regular flow continues.
Loading the same latest caps for the second time the caps are loaded from the
cache, skipping qemuTestParseCapabilitiesArch(). By skipping this function it
means that it also skips virQEMUCapsLoadCache() and, more relevant to
our case, virQEMUCapsInitHostCPUModel(). This function will use the
current arch and cpuModel settings to write the qemuCaps that are being
stored in the cache. And we're also setting FLAG_REAL_CAPS, meaning that
we won't be updating the qemucaps host model via testUpdateQEMUCaps() as
well.
This has side-effects such as:
- the first time the latest caps for an arch is loaded determines the
cpuModel it'll use during the current qemuxml2argvtest run. For
example, when running all tests, the first time the latest ppc64 caps
are read is on "disk-floppy-pseries" test. Since the current host arch
at this point is x86_64, the cpuModel that will be set for this
capability is "core2duo";
- every other latest arch test will use the same hostCPU as the first
one set since we read it from the cache after the first run.
qemuTestSetHostCPU() makes no difference because we won't update the
host model due to FLAG_REAL_CAPS being set. Using the previous example,
every other latest ppc64 test that will be run will be using the
"core2duo" cpuModel.
Using fake capabilities (e.g. using DO_TEST()) prevents FLAG_REAL_CAPS to
be set, meaning that the cpuModel will be updated using the current
settings the test is being ran due to testUpdateQEMUCaps().
Note that not all latest caps arch tests care about the cpuModel being
set to an unexpected default cpuModel. But some tests will care, e.g.
"pseries-cpu-compat-power9", and changing it from DO_TEST() to
DO_TEST_CAPS_ARCH_LATEST() will make it fail every time the
"disk-floppy-pseries" is being ran first.
One way of fixing it is to rethink all the existing logic, for example
not setting FLAG_REAL_CAPS for latest arch tests. Another way is
presented here. ARGS_CAPS_HOST_CPU_MODEL is a new testQemuInfo arg that
allow us to set any specific host CPU model we want when running latest
arch caps tests. This new arg can then be used when converting existing
DO_TEST() testcases to DO_TEST_CAPS_ARCH_LATEST() that requires a
specific host CPU setting to be successful, which we're going to do in
the next patch with "pseries-cpu-compat-power9".
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
qemuxml2xmltests that have "pseries" in the name now use the
DO_TEST_CAPS_LATEST_ARCH() macro.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Add nodedev schema parsing and format tests for the optional new device
address on the css devices.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@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>
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>
Unix socket chardevs with FD passing need to use the direct mode so we
need to convert it to use qemuFDPassDirect.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we store the state of the host FIPS mode setting in the qemu
driver object, we don't need to outsource the logic into
'qemuCheckFips'.
Additionally since we no longer support very old qemu's which would not
yet have --enable-fips we can drop the part of the comment about very
old qemus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Rather than re-query all the time we can cache the state of FIPS of the
host as it will not change during the runtime of the guest.
Introduce a 'hostFips' flag to 'virQEMUDriver' and move the code
checking the state from 'qemuCheckFips' to 'qemuStateInitialize' and
also populate 'hostFips' in qemuxml2argvtest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce 'qemuBuildCommandLineFlags' and use it instead of specific
flag booleans.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add support for the mode and add the corresponding qemuxml2argv test
case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'absolute' clock offset type has a 'start' attribute which is an
unix epoch timestamp to which the hardware clock is always set at start
of the VM.
This is useful if some VM needs to be kept set to an arbitrary time for
e.g. testing or working around broken software.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to always store the state of the feature in the
virDomainDef struct, otherwise
<smm state='off'/>
will incorrectly be interpreted as if the <smm> element was not
present.
Fixes: eeb94215b0
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This complements the existing smm=on tests. Looking at the output
files, one can immediately see how this case is currently not being
handled correctly. We're going to fix that in the next commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST() instead of hardcoding capabilities and
add the xml2xml part, which was missing; finally, rename it to
accomodate the complementary smm=off test that we're about to
introduce.
Signed-off-by: Andrea Bolognani <abologna@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>
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>
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>
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 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>
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>
Everything spice is not supported (and does not make sense) without spice
graphics. For some tests I also added cirrus VGA capability so that the XML
stays simple and libvirt can guess a default video model rather than adding too
much of an irrelevant XML into the individual tests.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
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>
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>
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 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>
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>
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>
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>
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>
On macOS when BROKEN_POLL is set in GLib, our tests will periodically
trigger a warning:
(process:50880): GLib-WARNING **: 02:54:15.272: poll(2) failed due to: Bad file descriptor.
Our code is inherantly racy, calling g_source_destroy which
removes the FD from the event thread poll asynchronously but
we close the FD immediately after g_source_destroy returns.
With poll() this results in POLLNVAL which we're ignoring, but
with select() it generates the BADF error on macOS.
We need to ignore the warnings on macOS to avoid abort()ing
our test programs.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/303
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Few minor changes in qemu since the last update:
- 'cocoa' display and corresponding props (not present in this build)
Changes in build:
- dbus display driver re-enabled
- gtk display support re-disabled
- xen support re-disabled
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend the 'disk-cdrom-network' to cover this instance. This also
validates that the parameters of -blockdev conform to the QAPI schema.
Also add the xml2xml variant of this test case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reject encryption requests for unsupported image format types.
Add negative test for the rejected cases as well as modify
'disk-network-rbd-encryption' case to validate that with librbd
encryption the format doesn't matter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was supposed to test the behavior when
QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT is present, but these
days that's always the case and pseries-cpu-compat already
provides all the coverage we need.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The capability is not used anymore since "-incoming defer" is supported
by all QEMU versions we care about.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Also, validate that the requested feature is supported by QEMU.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce QEMU_CAPS_VIRTIO_RSS capability which tracks
virtio-net.rss attribute introduced in qemu-5.2.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Added "rss" and "rss_hash_report" configuration that should be
used with qemu virtio RSS. Both options are triswitches. Used as
"driver" options and affects only NIC with model type "virtio".
In other patches - options should turn on virtio-net RSS and hash
properties.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The property is parsed using virTristateBoolTypeFromString() but
formatted as if it was a regular bool, which results in the
following incorrect conversion:
BOOL_ABSENT -> managed='no'
BOOL_YES -> managed='yes'
BOOL_NO -> managed='yes'
Use the virTristateBoolTypeToString() helper to ensure the
setting can survive a roundtrip conversion.
Fixes: 4b4a981d60
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Found when building on Fedora 36 on s390x.
C compiler for the host machine: gcc (gcc 12.0.1 "gcc (GCC) 12.0.1 20220308 (Red Hat 12.0.1-0)")
C linker for the host machine: gcc ld.bfd 2.37-24
In function ‘cpuTestUpdateLiveCompare’,
inlined from ‘cpuTestUpdateLive’ at ../dist-unpack/libvirt-8.2.5/tests/cputest.c:784:12:
../dist-unpack/libvirt-8.2.5/tests/cputest.c:696:21: warning: potential null pointer dereference [-Wnull-dereference]
696 | featAct->policy == VIR_CPU_FEATURE_REQUIRE) ||
| ~~~~~~~^~~~~~~~
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Starting with qemu-3.1 we always have the '-overcommit' argument and use
it instead of '-realtime'. Remove the capability check and fix all
fake-caps tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag was based on a version check which no longer made sense. Remove
the flag by replacing it's only use by an arch-check which is equivalent
at this point.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All qemu versions now support FD passing either directly or via FDset.
Assume that we always have this capability so that we can simplify
chardev handling in many cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-iommu needs to be an integrated device, and our address
assignment code will make sure that is the case. If the user has
provided an explicit address, however, we should make sure any
addresses pointing to a different bus are rejected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-iommu is a PCI device and attempts to use a different
address type should be rejected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
