Convert the rest of the outstanding tests to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real capabilities for the CPU test. The negative test case for QEMUs
without QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION is removed as the feature is
now supported by all supported qemu versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'hostdev-subsys-mdev-vfio-ccw', 'hostdev-vfio-zpci', and
'hostdev-vfio-zpci-autogenerate-fids' test cases have negative versions
which are invoked without capabilities. This does not make sense going
forward as the tests are going to be switched to real capabilities.
Remove them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the last outstanding test cases for ppc64 to use real
capabilities.
In couple cases this actually fixes the test case to test what it was
intending to do.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All of the tested features are always present in the 'pseries' machine
with oldest-supported qemu-4.2, thus the tests don't make sense any
more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an example case showing that every feature in the 'pseries-features'
test works also with the oldest supported qemu version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than using fake data and faking the host use the newly introduced
support for test variants to test the OSX HVF qemu version with real
data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than using fake data and faking the host use the newly introduced
support for test variants to test the OSX HVF qemu version with real
data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The changes to the output files are the exact opposite of
those from commit 22207713cf: this is proof that the fix is
working as intended, and that existing domains will keep using
raw firmware images regardless of whether or not qcow2 images
are available on the system and have higher priority.
New domains will keep picking whatever firmware is considered
the preferred one according to the order of descriptors, as
evidenced by the fact that the recently introduced
firmware-auto-efi-abi-update-aarch64 test case is unaffected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The input is identical to that of the existing
firmware-auto-efi-aarch64 test, but in this case we want to
cover the scenario in which that input is used to define a new
domain rather than loading the definition of an existing domain
from disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we're checking that firmware descriptor masking works
as intended by creating an empty file matching 60-ovmf-sb.json
in name.
However, that firmware descriptors contains the details for a
perfectly valid and quite common situation: Secure Boot being
supported by the firmware build, but being effectively disabled
by the lack of certificates in the NVRAM template.
Unmask that firmware descriptor, and instead create a dummy one
that has higher priority than all other OVMF builds and points
to paths that are obviously incorrect, which should make it
easy to notice it getting accidentally unmasked in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These cover the same scenarios as the matching test cases for
autoselection.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is identical to the existing
firmware-auto-efi-loader-path-nonstandard test case, but uses
a standard firmware path.
Right now the two test cases behave identically, but that's
going to change in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test is intended to simulate the use of an OVMF firmware
image installed under a non-standard path. In order to make
such a configuration work, the user would have to provide
additional information.
Right now it doesn't matter, because the configuration is
rejected anyway, but the behavior is going to change slightly
in the future. Prepare by making the configuration more
complete and realistic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This unifies the naming between the manual and automatic
selection cases, clarifies the contents of the tests and makes
room for more tests being added in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The newly added luks-any rbd encryption format in qemu
allows for opening both LUKS and LUKS2 encryption formats.
This commit enables libvirt uses to use this wildcard format.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This commit enables libvirt users to use layered encryption
of RBD images, using the librbd encryption engine.
This allows opening of an encrypted cloned image
whose parent is encrypted with a possibly different encryption key.
To open such images, multiple encryption secrets are expected
to be defined under the encryption XML tag.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When a thread-context object is specified on the cmd line, then
QEMU spawns a thread and sets its affinity to the list of NUMA
nodes specified in .node-affinity attribute. And this works just
fine, until the main QEMU thread itself is not restricted.
Because of v5.3.0-rc1~18 we restrict the main emulator thread
even before QEMU is executed and thus then it tries to set
affinity of a thread-context thread, it inevitably fails with:
Setting CPU affinity failed: Invalid argument
Now, we could lift the pinning temporarily, let QEMU spawn all
thread-context threads, and enforce pinning again, but that would
require some form of communication with QEMU (maybe -preconfig?).
But that would still be wrong, because it would circumvent
<emulatorpin/>.
Technically speaking, thread-context is an internal
implementation detail of QEMU, and if it weren't for it, the main
emulator thread would be doing the allocation. Therefore, we
should honor the pinning and prune the list of node so that
inaccessible ones are dropped.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2154750
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since qemuxml2argvtest is now using virnumamock, there's no need
for qemuxml2argvmock to offer reimplementation of virNuma*()
functions. Also, the comment about CLang and FreeBSD (introduced
in v4.3.0-40-g77ac204d14) is no longer true. Looks like noinline
attribute was the missing culprit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
So far, the memory-hotplug-dimm-addr.xml test case pins its vCPUs
onto CPUs 0-1 which correspond to NUMA node #0 (per
tests/vircaps2xmldata/linux-basic/system/node/node0). Place vCPUs
onto nodes #1 and #2 too so that DIMM <memory/> device can
continue using thread-context after future patches. This
configuration, as-is currently, would make QEMU error out anyway.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We have couple of qemuxml2argvtest cases where up to 8 NUMA nodes
are assumed. These are used to check whether disjoint ranges of
host-nodes= is generated properly. Without prejudice to the
generality, we can rewrite corresponding XML files to use up to 4
NUMA nodes and still have disjoint ranges.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Currently it's only possible to set this parameter during domain
creation via QEMU commandline passthrough feature.
With the new delay attribute it's also possible to set this
parameter if you want to attach a new NBD disk
using "virsh attach-device domain device.xml" e.g.:
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol='nbd' name='foo'>
<host name='example.org' port='6000'/>
<reconnect delay='10'/>
</source>
<target dev='vdb' bus='virtio'/>
</disk>
Signed-off-by: Christian Nautze <christian.nautze@exoscale.ch>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 54fa1b44af ("conf: Add loadparm boot option for a boot device")
added the ability to specify a loadparm parameter on a <boot/> tag, while
commit 29ba41c2d4 ("qemu: Add loadparm to qemu command line string")
added that value to the QEMU "-machine" command line parameters.
Unfortunately, the latter commit only looked at disks and network
devices for boot information, even though anything with
VIR_DOMAIN_DEF_FORMAT_ALLOW_BOOT could potentially have this tag.
In practice, a <hostdev> tag pointing to a passthrough (SCSI or DASD)
disk device can be used in this way, which means the loadparm is
accepted, but not given to QEMU.
Correct this, and add some XML/argv tests.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This can improve performance for some guests since it reduces copying of
display data between host and guest. Requires udmabuf on the host.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 24cc9cda82 switched over to use -machine hpet, but one of the
steps it did was to clear the QEMU_CAPS_NO_HPET capability.
The validation check still uses the old capability though which means
that for configs which would explicitly enable HPET we'd report an error.
Since HPET is an x86(_64) platform specific device, convert the
validation check to an architecture check as all supported qemu versions
actually support it.
Modify a test case to request HPET to catch posible future problems.
Fixes: 24cc9cda82
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemu-system-aarch64' is superset of the soon to be deprecated
'qemu-system-arm' binary. We can move over all of our fake-caps tests to
real caps on aarch64.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We always assert the flag for aarch64 qemus and in qemu the 'aarch64'
cpu property doesn't seem to be optional.
Remove checks and remove impossible test case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the 'ppc-dtb' and 'ppce500-serial' to use real capabilities
albeit captured from a non-native machine. Thus the XML needs to be
converted to use virt type 'qemu'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Preserve testing of the MMIO use case in case when GPEX is complied out
of qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the only outstanding test case for a 'sparc' machine to modern
test infrastructure.
'sparc' machine type also needs to be added to the list of supported
arches in testQemuGetLatestCaps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use x86_64 emulator and machine and remove the nocaps version of the
test.
Fixes: 80a37e96a9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Integrate the two special cases used for schema testing into the more
useful qemuxml2argvtest, whose input data is still tested against the
schema.
Add also a xml output variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These are allegedly necessary to keep the output consistent,
but now that we're using a privileged config for the driver we
get the desired behavior out of the box, and as a bonus the
paths match what you would actually see on a regular host.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
We use standard paths for almost everything else.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
For almost all directories, the value we set matches the one
a standard deployment would use, but in a couple of cases they
deviate from that. Keep things consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Our QEMU test suite effectively covers the qemu:///system
scenario, and we have to partially replace the unprivileged
config with its privileged equivalent after the fact to keep up
the illusion.
Instead of jumping through these extra hoops, we can simply
start with a privileged configuration matching the privileged
driver we're creating for test programs.
This change highlights that we were missing a couple of
overrides, specifically in the tests for passt and dbus. Now
that we're creating a privileged config, this kind of issue
shouldn't be able to slip into the test suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Follow the example of other similar settings and only enable it
for the few test cases that are actually about the specific
functionality, disabling it immediately afterwards.
A few test cases that were completely unrelated to SPICE TLS no
longer see the effects of having the feature enabled.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
QEMU deprecated the '-no-acpi' option, thus we should switch to the
modern way to use '-machine'.
Certain ARM machine types don't support ACPI. Given our historically
broken design of using '<acpi/>' without attribute to enable ACPI and
qemu's default of enabling it without '-no-acpi' such configurations
would not work.
Now when qemu reports whether given machine type supports ACPI we can do
a better decision and un-break those configs. Unfortunately not
retroactively.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/297
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove disks which are not necessary to demonstrate iothread config.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use latest caps for the tests even though the original test case didn't
need any capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the cputune-iothreads, cputune-iothreadsched-zeropriority,
cputune-iothreadsched test files by moving the relevant elements into
the cputune case as we can setup scheduler settings for multiple objects
and thus test everything in one go.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST for cputune-numatune, cputune-zero-shares,
cputune, and vcpu-placement-static cases. Do the necessary tweaks to
work with actual data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST for the basic tests. The emulator needed to be
tweaked to work with the real caps data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'iothreads-disk' covers everything that 'iothreads' did in addition to
actually using the iothread.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions now support iothreads thus upcoming patches
will be removing the capability checks. Remove the 'iothreads-nocap'
case which will become invalid.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These cover various scenarios related to firmware formats,
specifically ensuring that all the ways in which the user can
ask for a non-default format to be used work correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At the moment, if SMM is explicitly disabled in the domain XML
but a firmware descriptor that requires SMM to be enabled has
the highest priority and otherwise matches the requirements,
we pick that firmware only to error out later, when the domain
is started.
A better approach is to take into account the fact that SMM is
disabled while performing autoselection, and ignore all
descriptors that advertise the requires-smm feature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These cover scenarios such as using the new, more verbose
format of the <nvram> element to point to a local path, mixing
firmware autoselection with non-local NVRAM files, and
explicitly disabling SMM when using firmware autoselection.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Most of the differences, such as those in the domain name or
amount of memory, are fairly harmless, but they still make it
more cumbersome than necessary to directly compare different
input (and output) files.
More importantly, the use of unversioned machine types in some
of the test cases results in the descriptor-based autoselection
logic being effectively skipped, because the compatible machine
types as listed in them are only the versioned variants.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is already the case for the vast majority, but a few are
using explicit capabilities lists.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Most test cases are on 64-bit architectures already, but there
are a couple of exceptions.
Right now this works, but it will no longer fly after some
upcoming changes. Prepare for those by switching away from
32-bit architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU's "reconnect" option of "-netdev stream" tells QEMU to
periodically (period is given in seconds as an argument to the option)
attempt to reconnect to the same passt socket to which it had
originally connected to. This is useful in cases where the passt
process terminates, and libvirtd starts a new passt process in its
place (which doesn't happen yet, but will happen automatically after
an upcoming patch in this series).
Since there is no real hueristic for determining the "best" value of
the reconnect interval, rather than clutter up config with a knob that
nobody knows how to properly twiddle, we just set the reconnect timer
to 5 seconds.
"-netdev stream" first appeared in QEMU 7.2.0, but the reconnect
option won't be available until QEMU 8.0.0, so we need to check QEMU
capabilities just in case someone is using QEMU 7.2.0 (and thus can
support passt backend, but not reconnect)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Copy the pointer to qemuFDPass into struct qemuBlockStorageSourceAttachData
so that it can be used from qemuBuildBlockStorageSourceAttachDataCommandline
rather than looping again in qemuBuildDiskSourceCommandLineFDs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The <tune/> child element of <interface/> is formatted the old
way. Switch to virXMLFormatElement().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There's nothing specific about net-mtu test. In fact, if device
addresses are filled in (and some elements reordered), we get the
same XML. Make those changes to the input XML and turn the output
XML to be a symlink.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The iTCO watchdog is part of the q35 machine type since its inception,
we just did not add it implicitly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2137346
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is already possible with qemu, and actually already happening with
q35 machines and a specified watchdog since q35 already includes a
watchdog we do not include in the XML. In order to express such
posibility multiple watchdogs need to be supported.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Support virtio-crypto device, also support cryptodev types:
- builtin
- lkcf
Finally, we can launch a VM(QEMU) with one or more crypto devices by
libvirt.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce crypto device like:
<crypto model='virtio' type='qemu'>
<backend model='builtin' queues='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</crypto>
<crypto model='virtio' type='qemu'>
<backend model='lkcf'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</crypto>
Currently, crypto model supports virtio only, type supports qemu only
(vhost-user in the plan). For the qemu type, backend supports modle
builtin/lkcf, and the queues is optional.
Changes in this commit:
- docs: formatdomain.rst
- schemas: domaincommon.rng
- conf: crypto related domain conf
- qemu: crypto related
- tests: crypto related test
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update RISC-V capabilities for the QEMU 8.0.0 cycle. Changes made are
based on the JSONification of device parameters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
net-user-passt.args was generated early during testing of the passt
qemu commandline, when qemuxml2argvtest was using
DO_TEST("net-user-passt"). This was later changed to
DO_TEST_CAPS_LATEST(), so the file net-user-passt.x86_64-latest.args
is used instead, but the original (now unused) test file was
accidentally added to the original patch. This patch removes it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This attribute was added to support setting the --interface option for
passt, but in a post-push/pre-9.0-release review, danpb pointed out
that it would be better to use the existing <source dev='xxx'/>
attribute to set --interface rather than creating a new attribute (in
the wrong place). So we remove backend/upstream, and change the passt
commandline creation to grab the name for --interface from source/dev.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Currently, the ThreadContext object is generated whenever we see
.host-nodes attribute for a memory-backend-* object. The idea was
that when the backend is pinned to a specific set of host NUMA
nodes, then the allocation could be happening on CPUs from those
nodes too. But this may not be always possible.
Users might configure their guests in such way that vCPUs and
corresponding guest NUMA nodes are on different host NUMA nodes
than emulator thread. In this case, ThreadContext won't work,
because ThreadContext objects live in context of the emulator
thread (vCPU threads are moved around by us later, when emulator
thread finished its setup and spawned vCPU threads - see
qemuProcessSetupVcpus()). Therefore, memory allocation is done by
emulator thread which is pinned to a subset of host NUMA nodes,
but tries to create a ThreadContext object with a disjoint subset
of host NUMA nodes, which fails.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2154750
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This consists of (1) adding the necessary args to the qemu commandline
netdev option, and (2) starting a passt process prior to starting
qemu, and making sure that it is terminated when it's no longer
needed. Under normal circumstances, passt will terminate itself as
soon as qemu closes its socket, but in case of some error where qemu
is never started, or fails to startup completely, we need to terminate
passt manually.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Initial support for network devices using passt (https://passt.top)
for the backend connection will require:
* new attributes of the <backend> subelement:
* "type" that can have the value "passt" (to differentiate from
slirp, because both slirp and passt will use <interface
type='user'>)
* "logFile" (a path to a file that passt should use for its logging)
* "upstream" (a netdev name, e.g. "eth0").
* a new subelement <portForward> (described in more detail later)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Enable the qemuxml2xml variant and add output data for qemuxml2argvtest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'fdgroup' will allow users to specify a passed FD (via the
'virDomainFDAssociate()' API) to be used instead of opening a path.
This is useful in cases when e.g. the file is not accessible from inside
a container.
Since this uses the same disk type as when we open files via names this
patch also introduces a hypervisor feature which the hypervisor asserts
that code paths are ready for this possibility.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Up until commit 629282d884, using mode=restrictive caused
virNumaSetupMemoryPolicy() to be called from qemuProcessHook(),
and that in turn resulted in virNumaNodesetIsAvailable() being
called and the nodeset being validated.
After that change, the only validation for the nodeset is the one
happening in qemuBuildMemoryBackendProps(), which is skipped when
using mode=restrictive.
Make sure virNumaNodesetIsAvailable() is called whenever a
nodeset has been provided by the user, regardless of the mode.
https://bugzilla.redhat.com/show_bug.cgi?id=2156289
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The one for mode=strict fails, as expected, while the one for
mode=restrictive currently doesn't even though it should. The
next commit will address the issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The test is superseded by 'disk-backing-chains-(no)index' cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit da9f3cd84b added the seclabel example into the
'disk-backing-chains' case.
Since the only thing that 'disk-backing-chains' tests which
'disk-backing-chains-(no)index' don't test is the seclabel we'll be able
to remove the test case if we add the seclabel example.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
qemu is about to deprecate the '-no-hpet' option in favor of configuring
the timer via '-machine'.
Use the QEMU_CAPS_MACHINE_HPET capability to switch to the new syntax
and mask out the old QEMU_CAPS_NO_HPET capability at the same time to
prevent using the old syntax.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Introduce a new backend type 'external' for connecting to a swtpm daemon
not managed by libvirtd.
Mostly in one commit, thanks to -Wswitch and the way we generate
capabilities.
https://bugzilla.redhat.com/show_bug.cgi?id=2063723
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When generating memory for main guest memory memory-backend-*
might be used. This means, we may need to generate thread-context
objects too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When generating memory for memory devices memory-backend-* might
be used. This means, we may need to generate thread-context
objects too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When generating memory for guest NUMA memory-backend-* might be
used. This means, we may need to generate thread-context objects
too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
According to the result parsing from xml, add the argument of
SGX EPC memory backend into QEMU command line.
$ qemu-system-x86_64 \
...... \
-object '{"qom-type":"memory-backend-epc","id":"memepc0","prealloc":true,"size":67108864,"host-nodes":[0,1],"policy":"bind"}' \
-object '{"qom-type":"memory-backend-epc","id":"memepc1","prealloc":true,"size":16777216,"host-nodes":[2,3],"policy":"bind"}' \
-machine sgx-epc.0.memdev=memepc0,sgx-epc.0.node=0,sgx-epc.1.memdev=memepc1,sgx-epc.1.node=1
Signed-off-by: Lin Yang <lin.a.yang@intel.com>
Signed-off-by: Haibin Huang <haibin.huang@intel.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
JSON args for -netdev were added as precursor for adding the 'dgram'
network backend type. Enable the detection and update test cases using
DO_TEST_CAPS_LATEST.
Enabling the capability also ensures that the -netdev argument is
validated against the QAPI schema of 'netdev_add' which was already
implemented but not enabled.
The parser supporting JSON was added by qemu commit f3eedcddba3 and
enabled when adding stream/dgram netdevs in commit 5166fe0ae46.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu-6.2 introduced support for the hv-avic enlightenment which allows
to use Hyper-V SynIC with hardware APICv/AVIC enabled.
Implement the libvirt support for it.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/402
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.7.0-rc0~32^2~5 the .write-cache
attribute of virtio-blk dvice is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
The change in some .args is justified, because the qemuxml2argvdatatest
runs these test caseses with very minimalistic set of capabilities,
that's nowhere near real life scenario.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.9.0-rc0~48^2~25 the .share-rw
attribute of virtio-blk device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
The change in controller-order.args is justified, because the
qemuxml2argvdatatest runs the test case with very minimalistic
set of capabilities, that's nowhere near real life scenario.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v4.2.0-rc0~23^2~4 the .failover
attribute of virtio-net device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v3.0.0-rc0~124^2~1 the
set-numa-node command is always available for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As some qemxml2argvtest cases were removed, we forgot to remove
their expected output counterparts.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.11.0-rc0~95^2~9 the .discard
attribute of memory-backend-file is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.1.0-rc0~41^2~26 only for Linux,
and later in v3.1.0-rc0~71^2~10 for all POSIX, the
memory-backend-file is going to be present for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.1.0-rc0~41^2~104 the
memory-backend-ram is going to be present for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The aim of this test case it to make sure we error out when
QEMU_CAPS_OBJECT_MEMORY_RAM is missing. Well, it's never going to
be missing. Drop the test case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, we have maybe a dozen tests for hugepages related stuff in
qemuxml2xmltest. In all cases DO_TEST() is used, which means we have to
enumerate all capabilities needed (though, it's usually just
QEMU_CAPS_OBJECT_MEMORY_RAM and QEMU_CAPS_OBJECT_MEMORY_FILE,
exceptionally QEMU_CAPS_DEVICE_PC_DIMM too).
Instead of deleting the caps flags one-by-one, just switch the
tests to use DO_CAPS_LATEST().
Since some of our expected output files are just a symlink to their
respective input files, these are changed too. But from QEMU's
POV nothing changes as no .args file is changed.
Oh, and I'm also adding a 'hugepages-memaccess3' test case, which
was missing, surprisingly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, we have maybe a dozen tests for hugepages related
stuff in qemuxml2argvtest. In all cases DO_TEST() is used, which
means we have to enumerate all capabilities needed (though, it's
usually just QEMU_CAPS_OBJECT_MEMORY_RAM and
QEMU_CAPS_OBJECT_MEMORY_FILE, exceptionally
QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD too).
Instead of deleting the caps flags one-by-one, just switch the
tests to use DO_CAPS_LATEST().
The qemuxml2xmltest will undergo similar treatment in next
commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Glib can internally convert only unix timestamps up to
9999-12-31T23:59:59 (253402300799). Validate that the user doesn't use
more than that as otherwise we cause an assertion failure:
(process:1183396): GLib-CRITICAL **: 14:25:00.906: g_date_time_format: assertion 'datetime != NULL' failed
Additionally adjust the schema to allow bigger values as we use
'unsigned long long' to parse the value.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128993
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add data based on the v7.1.0-1579-g5107fd3eff qemu commit.
Notable changes:
- New machine types and corresponding objects:
- pc-i440fx-7.2, pc-i440fx-7.2-machine, pc-q35-7.2, pc-q35-7.2-machine
- new NETDEV_STREAM_CONNECTED/NETDEV_STREAM_DISCONNECTED events
- thread-context object and prealloc-property for memory devices added
- libblkio block driver backed support added:
- new backend protocol drivers:
- io_uring, nvme-io_uring, virtio-blk-vhost-user, virtio-blk-vhost-vdpa
- New CPU flags and some CPU features become migratable
(corresponding 'cpu-host-model' test changed output)
- cpu features 'avx', 'avx2', 'f16c', 'fma', 'vaes' became available in
TCG
- 'dumpdtb' command added
- New disk frontend properties:
- account-failed, account-invalid
- New unstable commands for debugging virtio:
x-query-virtio, x-query-virtio-status, x-query-virtio-queue-status,
x-query-virtio-vhost-queue-status, x-query-virtio-queue-element
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuxml2argvtest pseries-feature parse failure tests uses a symlink
to the pseries-features.xml test domain and control which feature it is
supposed to fail by excluding it from the capabilities list. The
advantage of this approach is that the same XML can be used in multiple
tests.
One downside is that any new pseries capability must be declared in all
existent tests, otherwise all other tests can break if this new
capability happens to be validated early in qemu_validate.c. Any new
parse_error test must declare all other existent capabilities.
Another downside is the fact that we're testing fairly improbable
scenarios: all pseries capabilities being tested here were introduced by
the same QEMU version, 4.2.0, at least as far as libvirt is aware of.
This means that it's no possible to have a scenario where, for example,
ccf-assist is not present but cfpc is. And last, but not the least, it's
getting in the way of our effort to convert all pseries tests to not use
explicit capabilities.
Changing all these tests to use DO_TEST_PARSE_ERROR_NOCAPS() will allow
us to test exactly what we want to test, which is the parse error given
for each feature if the binary does not have support for it. The XML
being used for each test can be simplified to just declare a single
feature. In the end we'll end up with more XML lines, but less
complexity inside qemuxml2argvtest.c.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Eliminate most of the pseries tests that are using explicit qemu caps
instead of CAPS_LATEST. The remaining tests will be handled in the next
patch.
The changes made are trivial: rename the .args/.err files to
ppc64-latest.(args/err) and do the required changes to match the newest
capabilities.
A notable expection were tests pseries-console-native,
pseries-serial-compat and pseries-serial+console-native. These are
aliases of the pseries-serial-native tests. In this case we needed to
re-create the symlink accordingly.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Introduced in libvirt by:
commit f245a9791c
qemu: introduce capability for virtual-css-bridge
Which mentions that its support was in QEMU 2.7.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Among the usual changes, this puts the virtio memballoon on the CCW bus.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Besides the -cpu host, The host-phys-bits=on applies to custom or max
cpu model, So the host-passthrough validation check is unnecessary for
maxphysaddr with mode='passthrough'.
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Added by QEMU commit:
commit 74b3e46630446568aecb0be1c77c4875d7a52f6d
Author: Jason Wang <jasowang@redhat.com>
CommitDate: 2019-10-25 07:46:22 -0400
virtio: add property to enable packed virtqueue
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191025083527.30803-9-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git describe: v4.1.0-1780-g74b3e46630 contains: v4.2.0-rc0~32^2~17
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Commit d7ae7ce363 forgot to clean up unused error output files
'boot-dev+order.err' and 'boot-menu-enable-with-timeout-invalid'
after converting tests to DO_TEST_CAPS_LATEST.
Fixes: d7ae7ce363
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The replacement is 'serial' and 'parallel' respectively introduced at
least in qemu-2.9 and the old versions are deprecated since qemu-6.0
(qemu commit 5965243641d797b22 ).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'index' is parsed to fit into a signed int but not have negative values.
virXMLPropInt can do that internally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As noted by the comments the only difference was the qemu capabilities
asserted. Now that we use only real caps for this test case it makes no
sense to have two copies.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turn them into DO_TEST_CAPS_VER bound to qemu-4.2 to show the minimum
amount of change. We already have DO_TEST_CAPS_LATEST versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Further patches will try to remove QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
so add few more modern tests before doing that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Using the modern emulator and arch will allow us to convert all of the
tests to use DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The support for 'sheepdog' was dropped from qemu-6.1 and later, to
convert the tests to latest caps we need to use something else. Use
'nbd'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced back in 2013 by QEMU commit:
commit 398489018183d613306ab022653552247d93919f
pc: limit 64 bit hole to 2G by default
Released in 1.6.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There is no need to specify an interface for a disk test.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The 'device_id' property of 'scsi_disk' was added in qemu-4.0 and it's
unconditionally present, thus we can now always assume its presence.
Update some fake-caps test which didn't yet assert the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Until we finish removing the capabilities we need to force them in the
tests so that it's obvious that the code changes have no impact.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modernize 'disk-nvme', 'encrypted-disk-usage', 'encrypted-disk', and
'user-aliases' cases to use DO_TEST_CAPS_LATEST.
This will remove all uses of QEMU_CAPS_QCOW2_LUKS from the test suite.
Since the output files are done via symlinks to input files, the input
files need to be modernized with few auto-added XML bits.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modernize the tests as they mostly care that the aliases are properly
propagated to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Generate only new version of the '-audiodev' commandline. The leftover
old code and validation will be removed in subsequent patches.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu version is going to be bumped to qemu-4.2. Upgrading the
version of these tests doesn't make sense as the host cpu in the real
capabilities doesn't support the features the tests are attempting to
test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu will be bumped to 4.2 so this test no longer makes sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu will be bumped to 4.2 so remove the older test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting from qemu-4.0 a new device model name is used instead of the
'disable_*' props. Since we are going to bump to qemu-4.2 as minimum
this test can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu version will be bumped to qemu-4.2 so we no longer need to
care about configuring audiodevs via the environment variables.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will bump minimum supported qemu version to 4.2 which
will use '-blockdev' with qemu so we can drop all the old test cases for
pre-blockdev configs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will bump minimum qemu version to 4.2. In this case we
the 'latest' case is sufficient as with qemu-4.2 we already behave as
upstream ('qemu64' cpu is used instead of 'qemu32').
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch maps /domain/cpu/maxphysaddr into -cpu parameters:
- <maxphysaddr mode='passthrough'/> becomes host-phys-bits=on
- <maxphysaddr mode='emualte' bits='42'/> becomes phys-bits=42
Passthrough mode can only be used if the chosen CPU model is
'host-passthrough'. Also validate that an explicitly specified
bits value does not exceed the physical address bits on the host.
The feature is available since QEMU 2.7.0.
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have all the machinery needed, we can introduce two
simple test cases:
1) only TPM 1.2 is supported, but TPM 2.0 was requested in domain XML,
2) only TPM 2.0 is supported, but TPM 1.2 was requested in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate memory related arguments into
qemuAppendDomainMemoryMachineParams(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which arguments are generated is changed.
But there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate arguments based on
domainDef->features[] into
qemuAppendDomainFeaturesMachineParam(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which features are generated is changed. But
there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Almost all of memory models we currently support allow setting
virDomainMemoryDef::targetNode so that the memory module is
associated with given guest NUMA node. And we do have a check
whether the requested node is within bounds, but it's executed
only when building QEMU's cmd line. Move it into validation
phase.
While this commit is moving the validation to a place that does
not validate all the possible code paths, it's okay, because only
the explicit memory device has user-configurable target node
which could break the assumption.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
So far, we are testing memory-hotplug-dimm-addr against a set of
explicitly listed capabilities. While this works, lets switch it
to DO_TEST_CAPS_LATEST() so that the latest capabilities are
used. This in turn means, we have to update the <emulator/>
because the latest capabilities don't contain caps for
qemu-system-i386.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When the <loader stateless='yes'/> attribute is set, the QEMU driver
needs to do three things
- Avoid looking for an NVRAM template
- Avoid auto-populating an <nvram/> path
- Find firmware descriptors with mode=stateless instead of mode=split
Note, the first thing happens automatically when we solve the second
thing.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Normally when an UEFI firmware is marked as read-only, an associated
NVRAM file will be created. Some builds of UEFI firmware, however, wish
to remain stateless and so will be read-only, but never have any NVRAM
file. To represent this concept a 'stateless' tristate bool attribute
is introduced on the <loader/> element.
There are rather a large number of permutations to consider.
With default firmware selection
* <os/>
=> Historic default, no change
* <os>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
With manual legacy BIOS selection
* <os>
<loader>/path/to/seabios</loader>
...
</os>
=> Historic default, no change
* <os>
<loader stateless='yes'>/path/to/seabios</loader>
...
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'>/path/to/seabios</loader>
...
</os>
=> Invalid, bios is always stateless
With manual UEFI selection
* <os>
<loader type='pflash'>/path/to/edk2</loader>
...
</os>
=> Historic default, no change
* <os>
<loader type='pflash' stateless='yes'>/path/to/edk2</loader>
...
</os>
=> Skip auto-filling NVRAM / template
* <os>
<loader type='pflash' stateless='no'>/path/to/edk2</loader>
...
</os>
=> Explicit version of historic default, no change
With automatic firmware selection
* <os firmware='bios'/>
=> Historic default, no change
* <os firmware='bios'>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os firmware='bios'>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
* <os firmware='uefi'/>
=> Historic default, no change
* <os firmware='uefi'>
<loader stateless='yes'/>
</os>
=> Skip auto-filling NVRAM / template
* <os firmware='uefi'>
<loader stateless='no'/>
</os>
=> Explicit version of historic default, no change
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Note that we can only do this for intel-iommu and virtio-iommu,
which are configured using -device; smmuv3 is configured using
a machine type property, so there's no room on the command line
for an alias in that case.
https://bugzilla.redhat.com/show_bug.cgi?id=2108483
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU offers two attributes for handling reset requests of an USB
host device: guest-reset and guest-resets-all. When combined they
act as follows:
1) guest-reset=false
The guest is not allowed to reset the physical USB device.
2) guest-reset=true,guest-resets-all=false
The guest is allowed to reset the device when it is not yet
initialized (aka no USB bus address assigned). Usually this results
in one guest reset being allowed. This is the default behavior.
3) guest-reset=true,guest-resets-all=true
The guest is allowed to reset the device as it pleases.
Now, there's a clear 1:1 mapping with our representation of
guestReset, so generating cmd line is trivial.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some USB devices have a buggy firmware that either crashes on
device reset, or make the device unusable in some other way.
Fortunately, QEMU offers a way to skip device reset either
completely, or if device is not initialized yet. Expose this
ability to users under:
<hostdev mode='subsystem' type='usb'>
<source guestReset='off'/>
</hostdev>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, we have bunch of PCI/USB tests cases for
qemuxml2argvtest and qemuxml2xmltest but all of them run without
any capabilities. This makes is needlessly complicated when
trying to extend them. Switch to DO_TEST_CAPS_LATEST().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend the test for io_uring to also test startup policy.
Since the actual logic for dropping disks is in the host preparation
phase, thus skipped for tests we can use any file path.
Add a case also for 'file' backing to have all cases covered.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu commandline is identical with the '-latest' version so there's
no need for a separate case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test was showing that the 'blockdev' capability is properly added
although we didn't detect it yet. Unfortunately this test can't be
carried over once we bump minimum qemu version to qemu-4.2.
Make the test case future-proof by removing the qemu-4.0.0 version which
would become pointless and use only already deprecated capability flags
so that the test output does not change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested net device has the same syntax with latest qemu so there's no
need to have a version-locked test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu feature formatting doesn't change between the versions thus we
can just keep the '-latest' versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested feature doesn't change across versions so we can use the
modern testing infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The version-locked version of the test data is identical to the 'latest'
version so we can remove them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prior to qemu-3.2 we'd have to disable the 'pconfig' feature explicitly
which is no longer needed with new qemu. Remove the version locked to
qemu-3.1 as the 'latest' case sufficiently handles what we want to test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, a firmware configuration such as
<os firmware='efi'>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
</firmware>
</os>
will correctly pick a firmware that implements the Secure Boot
feature and initialize the NVRAM file so that it contains the
keys necessary to enforce the signing requirements. However, the
lack of a
<loader secure='yes'/>
element makes it possible for pflash writes to happen outside
of SMM mode. This means that the authenticated UEFI variables
where the keys are stored could potentially be overwritten by
malicious code running in the guest, thus making it possible to
circumvent Secure Boot.
To prevent that from happening, automatically turn on the
loader.secure feature whenever a firmware that implements Secure
Boot is chosen by the firmware autoselection logic. This is
identical to the way we already automatically enable SMM in such
a scenario.
Note that, while this is technically a guest-visible change, it
will not affect migration of existings VMs and will not prevent
legitimate guest code from running.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:
* we still want the path to the NVRAM file to be customizable;
* using <loader secure='yes'/> was how you would ask for a
firmware that implements the Secure Boot feature in the
original approach to firmware autoselection, so we want to
keep that working.
Anything else should result in a descriptive error.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This combination doesn't make sense and so the firmware
autoselection logic will not be able to find a suitable firmware,
but it's more user-friendly to report a detailed error upfront.
Note that this check would ideally happen in the validate phase,
but if we moved it there we would no longer be able to
automatically enable secure-boot when enrolled-keys=yes. Since
the combination never resulted in a working configuration, the
chances of this causing real-world VMs to disappear are
extremely low.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the lack of a <loader> element results in the <nvram>
element being completely ignored, but this is unnecessarily
limiting: even when firmware autoselection is in use, it should
be possible for the user to specify a custom path for the NVRAM
file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that some of these new tests are displaying incorrect or
suboptimal behavior. When we address those in upcoming patches,
this will be highlighted by changes in the test data.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This currently has not effect whatsoever, so it's just cluttering
the input files.
We're going to add specific handling for this scenario, as well
as a test case covering it, in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This does the opposite of
commit 392292cd99
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Wed Feb 23 12:45:51 2022 +0000
tests: don't use auto-generated NVRAM path in tests
in order to minimize input files.
We're going to add a test case specifically covering the use of
custom NVRAM paths with firmware autoselection in an upcoming
commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When testing firmware selection, we don't really care about any
of the hardware assigned to the VM, and in fact it's better to
keep it as minimal as possible to make sure that the focus
remains on the firmware bits.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Group all tests related to firmware selection together and give
them consistent names that leave room for further tests to be
added in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was introduced in
commit 5882064084
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Wed Feb 25 15:45:26 2015 +0100
tests: Add test for os interleaving
to ensure a recent change in the schema was behaving correctly.
Seven years later, it no longer seems very useful to keep it
around.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This simplifies the test data without negatively impacting test
coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The pci-bridge-many-disks test case is not related to firmware
handling at all, so we can trim it without losing any coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
