The qemu driver explicitly rejects such configuration, thus this is just
a generic XML2XML test case. Move it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The case was removed in commit 8ff73d22c7
which modernized the cases without an explicit reason. Reinstate it.
Fixes: 8ff73d22c7
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The test case was introduced by commit 68599168ea
but is only used in the qemunbdkittest. Fix it and make use of it also
in qemuxml2argvtest.
Fixes: 68599168ea
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The tests invocations were accidentaly removed in commit
54257ed51b
Fixes: 54257ed51b
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently when we build with nbdkit support, libvirt will always try to
use nbdkit to access remote disk sources when it is available. But
without an up-to-date selinux policy allowing this, it will fail.
because the required selinux policies are not yet widely available, we
have disabled nbdkit support on rpm builds for all distributions before
Fedora 40.
Unfortunately, this makes it more difficult to test nbdkit support.
After someone updates to the necessary selinux policies, they would also
need to rebuild libvirt to enable nbdkit support. By introducing a
configure option (nbdkit_config_default), we can build packages with
nbdkit support but have it disabled by default.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Suggested-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
virNetServerAddService() return value is invariant, so change it
type and remove all dependent checks.
Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU 8.2 was released, update the x86_64 data for a final time.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Allow the user to manually tweak the ID mapping that will allow
virtiofsd to run unprivileged.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Prepare the blockdev props formatter to skip formatting the slice props
in case they are not applicable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than pulling the configuration of the storage slice into the
'format' layer make the 'slice' layer effective for raw disks with a
storage slice. This was made possible by the recent refactors which made
the 'format' layer optional if not needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
DO_TEST_CPUID(arch, host, json) is a multipart test. It consists of the
following tests:
- cpuTestHostCPUID()
- cpuTestGuestCPUID(with JSON_* flag)
- cpuTestCPUIDSignature()
- DO_TEST_JSON():
- if json==JSON_MODELS:
- cpuTestGuestCPUID(without JSON_* flag)
- cpuTestJSONCPUID()
- cputestJSONSignature()
Notice that for tests with json==JSON_MODELS, cpuTestGuestCPUID() is
actually called twice but with different arguments. The first one passes
JSON_MODELS to the test function, while the second one passes 0.
The main difference in behavior when calling cpuTestGuestCPUID() with or
without the flag is that in the first case, it parses the captured qemu
output from $ARCH-cpuid-$CPU.json. It extracts the cpu model list from
that JSON, and uses that to filter out possible cpu models to match.
In other words, it tries to match the cpu to a model that was supported
by the qemu version that was used to generate this JSON file. When it
finds a match, it generates a cpu definition and compares the xml form
of that definition with the file $ARCH-cpuid-$CPU-guest.xml.
When called without the JSON_MODELS flag, it simply attempts to match it
against the full libvirt cpu map and doesn't attempt to filter out any
matches based on the JSON qemu cpu model list. After it finds a match,
it generates an xml definition for the cpu and compares it to the same
file listed above. So if these two invocations disagree on the cpu match
(e.g. because libvirt has added a cpu model to its cpu map that matches
better than one that was supported by the version of qemu that generated
the JSON file) the test will fail.
This duplicate call to cpuTestGuestCPUID() was originally added in
commit 49c945a6f5. The original
justification for that commit was to fix test failures when the Qemu
driver was disabled. But since DO_TEST_JSON() is #defined empty when
qemu is disabled, this particular invocation would not even be executed
in this scenario, so it doesn't seem relevant.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the low level monitor API directly to test the QMP wrapper itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu allows and in some cases uses protocol driver names ('file',
'host_device', 'nbd', ...) in the 'backing file format' field of a qcow
to denote a image where the dummy 'raw' driver was not used on top.
Adapt our backing store parser for such cases. The examples added in
previous patch show the difference in behaviour.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU allows and in cases where you omit the not-strictly-needed 'raw'
driver on top of raw images automatically uses the protocol name inside
of the 'backing file format' field of the qcow2 image.
Libvirt expects only format names in that field.
Add example images showing this scenario, which will be fixed later.
The qcow2 image files in this commit were formatted as:
qemu-img create -f qcow2 -F nbd -b nbd+tcp://example.org:6000/blah -u qcow2-protocol-backing-nbd.qcow2 10M
and
qemu-img create -f qcow2 -F file -b raw qcow2-protocol-backing-file.qcow2
thus using 'nbd' and 'file' as backing format respectively.
(note that '-b raw' refers to the file in the example image folder)
To satisfy the test, note that the NBD image is also rejected as we
can't probe it, thus such configuration would not work.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Compare also the detected format of the backing file
('backingStoreRawFormat' field) into the output data for comparison with
others. Since the ToString function can't convert VIR_STORAGE_FILE_AUTO
use also the numeric value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is mostly straightforward, except for a teensy-weensy
detail: usually, there's no system wide daemon running, no system
wide available socket that anybody could connect to. PipeWire
uses a per user daemon approach instead. But this in turn means,
that the socket location floats between various locations and is
derived from various environment variables (just like the actual
socket name) and thus we must pass the variables to QEMU.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/560
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU gained support for PipeWire audio backend (see QEMU commit
of v8.0.0-403-gc2d3d1c294). Its configuration knobs are basically
the same as pulseaudio's, except for PA's server name. Therefore,
a lot of code is copied over from pulseadio and fixed by
s/Pulse/Pipewire/ or s/pulseaudio/pipewire/.
There's one ley difference to PA though: pipewire daemon is
usually on per user basis (just like our qemu:///session).
Therefore, introduce this 'runtimeDir' attribute, which allows
specifying path to pipewire daemon socket (useful for
qemu:///system for instance).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Differences from qemu:
* "vmx-ept-uc" (bit 8) and "vmx-ept-wb" (bit 14) are not added to
qemu's list of named features yet, but used in several qemu cpu
models never the less. Add to libvirt regardless.
* "vmx-invvpid-single-context" (bit 41) is erroneously called
"vmx-invept-single-context" in qemu. This is the name of the
feature associated with bit 25 in both libvirt and qemu.
* "vmx-invvpid-single-context-noglobals" (bit 43) is erroneously
called "vmx-invept-single-context-noglobals". Use the correct name.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While glibc provides qsort(), which usually is just a mergesort,
until sorting arrays so huge that temporary array used by
mergesort would not fit into physical memory (which in our case
is never), we are not guaranteed it'll use mergesort. The
advantage of mergesort is clear - it's stable. IOW, if we have an
array of values parsed from XML, qsort() it and produce some
output based on those values, we can then compare the output with
some expected output, line by line.
But with newer glibc this is all history. After [1], qsort() is
no longer mergesort but introsort instead, which is not stable.
This is suboptimal, because in some cases we want to preserve
order of equal items. For instance, in ebiptablesApplyNewRules(),
nwfilter rules are sorted by their priority. But if two rules
have the same priority, we want to keep them in the order they
appear in the XML. Since it's hard/needless work to identify
places where stable or unstable sorting is needed, let's just
play it safe and use stable sorting everywhere.
Fortunately, glib provides g_qsort_with_data() which indeed
implement mergesort and it's a drop in replacement for qsort(),
almost. It accepts fifth argument (pointer to opaque data), that
is passed to comparator function, which then accepts three
arguments.
We have to keep one occurance of qsort() though - in NSS module
which deliberately does not link with glib.
1: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=03bf8357e8291857a435afcc3048e0b697b6cc04
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Upcoming test bump will cause some changes thus preserve the existing
state.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
CPU host model expansion depends on the CPU data from the capabilities
and can change based on emulation type. Add complementary tests to the
ones we already have to ensure full coverage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu-host-model.xml test case uses 'kvm' whereas the
fallback/nofallback cases use tcg in the definition. Rename them
accordingly so that the complement cases can be added later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Migration compression parameters 'compress-level', 'compress-threads',
'decompress-threads' were deprecated by qemu. Drop them from the tests.
Note that the migration code automatically checks whether given
capability is supported by qemu and thus we don't need to add any
further code to prepare for the legacy compression to be dropped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some sub-tests dereference 'data->vm' even when it is NULL.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Xcode 15, which provides the compiler toolchain for building libvirt
on macOS has switched to a new linker that warns about duplicated
"-lblah" options on the ld commandline. In practice this is impossible
to prevent in a large project, and also harmless.
Fortunately the new ld command also has an option,
-no_warn_duplicate_libraries, that supresses this harmless/pointless
warning, meson has a simple way to check if that option is supported,
and libvirt's meson.build files already have examples of adding an
option to the ld commandline if it's available.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This environment variable is supposedly set according to the contents
of ~/.CFUserTextEncoding, and certainly on MacOS 14 (Sonoma) it is set
in the environment of child processes created by execve() (used by
virCommand()), causing commandtest to fail. (However, the value that is
shown in $__CF_USER_TEXT_ENCODING during the test 1) is not in the
environment of the shell the test is run from, and 2) doesn't match
the contents of ~/.CFUserTextEncoding.)
It is true, though, that filtering out this environment setting from
the test results permits commandtest to pass on macOS 14 (Sonoma).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
QEMU_BLOCK_STORAGE_SOURCE_BACKEND_PROPS_SKIP_UNMAP is no longer
referenced inside the code.
QEMU_BLOCK_STORAGE_SOURCE_BACKEND_PROPS_AUTO_READONLY is passed from
various code paths to the qemuBlockStorageSourceGetBackendProps helper,
but it's no longer used.
Both thus can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new helper in qemuBlockStorageSourceGetBlockdevStorageSliceProps
to format the common bits.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the same ordering of the relevant fields as we do for the format
layer -blockdev so that later they can be refactored without test
fallout.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Legacy mode used to be needed for use with -drive, which was almost
completely deleted. We now have qemuxml2argvtest test cases checking a
few cases and the rest uses the modern mode only. Thus we don't need to
test the legacy mode any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Condition handling failure of the first virTestRun was lacking the 'ret
= -1' line thus the subsequent line was taken as it's body rendering the
first invocation useless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU deprecated and removed support for those protocols, but due to a
logic bug in the tests it was not caught. Remove the test cases first.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update to v8.1.0-2161-ga95260486a
Notable changes:
- new CPU topology parameters: 'books', 'drawers'
- new migration parameter 'avail-switchover-bandwidth'
- new s390x CPU properties: 'dedicated', 'entitlement'
- new 'hostmem' parameter for 'virtio-gpu'
- new device 'piix4-isa'
- new property 'dynamic-memslots' of 'virtio-mem' device
- new 'gsi*' parameters of 'ICH9-LPC'
- new experimental 'x-south-bridge' machine option
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Test cases that depend on duplicating fds are using fairly big
values as targets.
This works fine on Linux, where RLIMIT_NOFILE is 1024 by
default, but fails on macOS which uses 256 as the default.
Decrease the values so that they're valid across all platforms.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Both tests pass a disk source definition which didn't go through the
preparation steps and thus contains only the target information that
were originally present, thus we should be using the
QEMU_BLOCK_STORAGE_SOURCE_BACKEND_PROPS_TARGET_ONLY flag.
For the same reason QEMU_BLOCK_STORAGE_SOURCE_BACKEND_PROPS_AUTO_READONLY
used in 'testJSONtoJSON' doesn't make sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a few examples of SD cards backed with network storage to capture
the current state as the formatter code is about to be refactored.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test code cares mostly about the actual layer nodenames thus,
appropriate accessors are used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert all places in tests to use the 'storage' layer nodename
accessors instead of (virStorageSource)->nodestorage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuBlockStorageSourceGetFormatProps as it formats the properties of
the 'format' driver in qemu. Adjust the comment which was hinting
otherwise.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the node name of the storage access driver to identify the block job
volumes. This will prepare the blockjob code for the possibility that the
format layer may be missing. Our lookup code can find either of them,
thus we can safely switch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Enable the flags in the status xml2xmtest and add an exaple to the test
data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that deleting and reverting external snapshots is implemented we can
report that in capabilities so management applications can use that
information and start using external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As of v9.4.0-rc2~5 it is possible to specify guest address where
a virtio-mem/virtio-pmem memory device is mapped to. What that
commit forgot to introduce was a check for overlaps.
And yes, this is technically an O(n^2) algorithm, as
virDomainMemoryDefValidate() is called over each memory device
and after this, virDomainMemoryDefValidate() also iterates over
each memory device. But given there's usually only a handful of
such devices, and this runs only when parsing domain XML I guess
code readability wins over some less obvious solution.
Resolves: https://issues.redhat.com/browse/RHEL-4452
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current message can be misleading, because it seems to suggest
that no firmware of the requested type is available on the system.
What actually happens most of the time, however, is that despite
having multiple firmwares of the right type to choose from, none
of them is suitable because of lacking some specific feature or
being incompatible with some setting that the user has explicitly
enabled.
Providing an error message that describes exactly the problem is
not feasible, since we would have to list each candidate along
with the reason why we rejected it, which would get out of hand
quickly.
As a small but hopefully helpful improvement over the current
situation, reword the error message to make it clearer that the
culprit is not necessarily the firmware type, but rather the
overall domain configuration.
Suggested-by: Michael Kjörling <7d1340278307@ewoof.net>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It's not possible to use password-protected ssh keys directly with
libvirt because libvirt doesn't have any way to prompt a user for the
password. To accomodate password-protected key files, an administrator
can add these keys to an ssh agent and then configure the domain with
the path to the ssh-agent socket.
Note that this requires an administrator or management app to
configure the ssh-agent with an appropriate socket path and add the
necessary keys to it. In addition, it does not currently work with
selinux enabled. The ssh-agent socket would need a label that libvirt
would be allowed to access rather than unconfined_t.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For ssh disks that are served by nbdkit, we can support logging in with
an ssh key file. Pass the path to the configured key file and the
username to the nbdkit process.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For ssh disks that are served by nbdkit, use the configured value for
knownHosts and pass it to the nbdkit process.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For ssh disks that are served by nbdkit, lookup the password from the
configured secret and securely pass it to the nbdkit process using fd
passing.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Adds the ability to monitor the nbdkit process so that we can take
action in case the child exits unexpectedly.
When the nbdkit process exits, we pause the vm, restart nbdkit, and then
resume the vm. This allows the vm to continue working in the event of a
nbdkit failure.
Eventually we may want to generalize this functionality since we may
need something similar for e.g. qemu-storage-daemon, etc.
The process is monitored with the pidfd_open() syscall if it exists
(since linux 5.3). Otherwise it resorts to checking whether the process
is alive once a second. The one-second time period was chosen somewhat
arbitrarily.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We were testing the arguments that were being passed to qemu when a disk
was being served by nbdkit, but the arguments used to start nbdkit
itself were not testable. This adds a test to ensure that we're invoking
nbdkit correctly for various disk source definitions.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For virStorageSource objects that contain an nbdkitProcess, start that
nbdkit process to serve that network drive and then pass the nbdkit
socket to qemu rather than sending the network url to qemu directly.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add xml to the private data for a disk source to represent the nbdkit
process so that the state can be re-created if the libvirt daemon is
restarted. Format:
<nbdkit>
<pidfile>/path/to/nbdkit.pid</pidfile>
<socketfile>/path/to/nbdkit.socket</socketfile>
</nbdkit>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add new DO_TEST_CAPS_LATEST_NBDKIT macro to test xml2argv for various
nbdkit capability scenarios.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There was support in the code for parsing protocol='ssh' on network disk
sources, but it was not present in the xml schema. Add this to the
schema.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since commit 54257ed51b on S390x qemuxml2argvtest fails with the following errors:
144) QEMU XML-2-ARGV cpu-kvmclock.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.883+0000: 4113077: info : libvirt version: 9.8.0
2023-09-14 13:01:23.883+0000: 4113077: info : hostname: a46lp61.lnxne.boe
2023-09-14 13:01:23.883+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
1059) QEMU XML-2-ARGV cpu-check-partial.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.885+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
1064) QEMU XML-2-ARGV cpu-check-default-partial2.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.885+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
3 tests failed.
Fixes: 54257ed51b
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Requires recent qemu with support for the virtio-blk-vhost-vdpa device
and the ability to pass a /dev/fdset/N path for the vdpa path (8.1.0)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1900770
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuInterfaceVDPAConnect() was a helper function for connecting to the
vdpa device file. But in order to support other vdpa devices besides
network interfaces (e.g. vdpa block devices) make this function a bit
more generic.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Check whether the qemu binary supports the vdpa block driver. We can't
rely simply on the existence of the virtio-blk-vhost-vdpa block driver
since the first releases of qemu didn't support fd-passing for this
driver. So we have to check for the 'fdset' feature on the driver
object. This feature will be present in the qemu 8.1.0 release and was
merged to qemu in commit 98b126f5.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This was added in qemu commit 166b174188.
No additional features had to be added to libvirt.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Now that all fake-caps testing was removed we can also remove the
filling of the fake caps by cpu models.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove all the code for adding fake machines into the testing capability
cache as we no longer have any machines in it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The status XML doesn't require any capabilities to be parsed and
formatted back. Remove all qemuCaps related code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that all tests were converted to use real capabilities we can drop
x86_64 from the tooling to create fake capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The rest of the test cases has no change in the output now that we've
assumed some flags.
Remove the fake-caps test macros after conversion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real capabilities, but select the fake 'Haswell' host CPU for test
stability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously without modern capabilities the test was relying on a CPU
model which was not entered into a fake list of supported cpus.
With real capabilities we have to pick a CPU model which is supported by
libvirt but in some version is not supported by qemu. I've picked
EPYC-Milan, which was introduced into qemu-6.0.
This test configures a CPU which is equivalent to EPYC-Rome by disabling
features from EPYC-Milan and uses a versioned real caps test to check it
against a qemu which doesn't support EPYC-Milan.
With real capabilities though, we can also do a positive test case by
using a version whic doesh support it. I've specifically not used the
LATEST caps so that it doesn't change once capabilities are bumped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the fake Haswell processor definition and augment the list of
features to make the test pass.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real capabilities, but select the fake 'Haswell' host CPU for test
stability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modernize all test cases which set 'Haswell' as the host cpu model.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modernize test cases using 'host-mode' cpu type, where the actual CPU
doesn't isn't important.
As using the host cpu from the 'latest' capabilities data would cause
test churn in case the host cpu changes in the future, convert them
using the overriden Haswell cpu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the 'smp-dies' test case into 'cpu-topology4' and remove
unnecessary cruft.
Remove cpu definition from 'cpu-topology2' as it's not relevant to the
test case.
Remove 'smp' case as it's covered by the rest.
Use real capabilities for all of them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As these were using DO_TEST_FULL the churn-reducing patches didn't
influence these.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since qemu-8.0 a new way to disable 'hpet' via -machine was added.
Properly test both branches with real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assume the features modern qemus have to bring the test data closer
to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assume the two features modern qemus have to bring the test data closer
to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assume the two features modern qemus have to bring the test data closer
to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assume the support for the 'pcie-root-port' all modern qemus have to
bring the test data closer to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To minimize further churn when coverting to real capabilities, assume
that all fake-caps machines support the piix3 USB controller.
Since we already have solid testing of USB controllers, this will have
effect only in cases when it's not relevant to the test itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename the 'usb-controller-explicit-(unavailable-)q35' test case to
'usb-controller-nec-xhci'. Since this also covers what
'usb-controller-xhci' was testing the latter is removed.
Other 'usb-xhci' test cases which were using the NEC controller are also
renamed to contain the name.
In case of 'usb-controller-qemu-xhci' the negative test case is deleted
as we don't need two cases for missing explicitly specified controller
and the positive case is modernized to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Improve testing of an explicitly requested USB controller without a
model being provided.
For this purpose the 'usb-controller' case is renamed to
'usb-controller-default-i440fx'; 'usb-controller-default-q35' is moved
up to form a group. In both cases tests are covnerted to use
DO_TEST_CAPS_LATEST.
A new 'usb-controller-default-isapc' negative test case is added for
symmetry.
The negative test case 'usb-controller-default-unavailable-q35' is
converted to use latest caps, but stripping the default controller
instead of using fake caps. Additionally for symmetry
'usb-controller-default-unavailable-i440fx' is added although that
doesn't cause failure, but rather a graceful downgrade to use '-usb'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are per-machine type variations on which usb controller will be
picked on an x86_64 machine. Add test cases where a USB controller is
completely missing to cover all 3 cases ('isapc', 'pc', 'q35') when an
USB controller is not explicitly requested by the user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move all controller related tests together and consolidate naming of the
test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In order to minimize further churn, make all fake-caps test assume that
the seccomp sandbox is supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
