Problem with current approach is that if
qemuSecuritySetAllLabel() fails, then the @chown_paths and
@xattr_paths hash tables are not freed and preserve values
already stored there into the next test case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
I don't really know what happened when I was writing the original
code, but even if error was to be set the corresponding boolean
was set to false meaning no error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
One of the functions of this mock is that it spoofs chown() and
stat() calls. But it is doing so in a clever way: it stores the
new owner on chown() and reports it on subsequent stat(). This is
done by using a 32bit unsigned integer where one half is used to
store uid the other is for gid. Later, when stat() is called the
integer is fetched and split into halves again. Well, my bit
operation skills are poor and the code I've written does not do
that properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test is beautiful. It checks if we haven't messed up
refcounting on security labels (well, XATTRs where the original
owner is stored). It does this by setting up tracking of XATTR
setting/removing into a hash table, then calling
qemuSecuritySetAllLabel() followed by immediate
qemuSecurityRestoreAllLabel() at which point, the hash table must
be empty. The test so beautifully written that no matter
what you do it won't fail. The reason is that all seclabel work
is done in a child process. Therefore, the hash table in the
parent is never changed and thus always empty.
There are two reasons for forking (only one of them makes sense
here though):
1) namespaces - when chown()-ing a file we have to fork() and
make the child enter desired namespace,
2) locking - because of exclusive access to XATTRs we lock the
files we chown() and this is done in a fork (see 207860927a for
more info).
While we want to fork in real world, we don't want that in a test
suite. Override virProcessRunInFork() then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Our code would skip adding the default type in this cases, but since we
know that the only reasonable option here is 'fat' we can add it while
starting the VM.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The storage volume may in fact convert into a directory when starting
the VM so that it may be actually possible to use it.
This is a regression caused by c9b27af32d as moving the check to
validation time without adjustment causes problems as the volumes are
not translated yet.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We didn't do this earlier because the DO_TEST_CAPS_ARCH_LATEST()
macro was limited to qemuxml2argv until recently.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Support for this has only relatively recently been added to
virt-manager.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the latest virt-manager to regenerate the files.
The command line is once again along the lines of
$ virt-install \
--name guest --os-variant fedora29 \
--vcpus 4 --memory 4096 --disk size=5 \
--graphics (none|vnc) \
--print-xml
with some minor tweaks performed afterwards.
This removes a number of inconsistencies between the files,
and makes it so the only differences are actually relevant
either to the architecture and machine type at hand, or to
having graphics rather than being headless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now *-headless and *-graphics tests are using different
quoting styles, which results in the diff between them being
basically useless, whereas we would like it to be possible to
compare these files directly and easily spot the differences.
Convert all *-graphics tests to single quotes, which is the
style libvirt itself uses when formatting XML: this is a fact
that will come in handy later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit a7fb2258 added sanitization of storage pool target paths,
however source dir paths were left unsanitized.
A netfs pool with:
<source>
<host name='10.20.30.40'/>
<dir path='/nfs/'/>
</source>
will not be correctly detected as mounted by
virStorageBackendFileSystemIsMounted, because it shows up in the
mount list without the trailing slash.
Sanitize the source dir as well.
https://bugzilla.redhat.com/show_bug.cgi?id=1723247
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The function modifies the context but did not care to restore it back.
If a <seclabel> was used on a disk, the <privateData> would not be
parsed.
Use VIR_XPATH_NODE_AUTORESTORE and add a test case to validate that
everything works.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Show that the capability tweaking stuff works by enabling blockdev in
the 'qemu-ns' test even in versions where it's not yet fully supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the DO_TEST_CAPS_LATEST/VER infrastructure to run a more modern
version of this and also fork it to a pre-blockdev version so that we
can check the qemu namespace capability tweaking.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly how we allow adding arbitrary command line arguments and
environment variables this patch introduces the ability to control
libvirt's perception of the qemu process by tweaking the capability bits
for testing purposes.
The idea is to allow developers and users either test a new feature by
enabling it early or disabling it to see whether it introduced
regressions.
This feature is not meant for production use though, so users should
handle it with care.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirtd has long had integration with avahi for advertising libvirtd
using mDNS when TCP/TLS listening is enabled. For a long time the
virt-manager application had support for auto-detecting libvirtds
on the local network using mDNS, but this was removed last year
commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
Author: Cole Robinson <crobinso@redhat.com>
Date: Sat Oct 6 20:55:31 2018 -0400
connect: Drop avahi support
Libvirtd can advertise itself over avahi. The feature is disabled by
default though and in practice I hear of no one actually using it
and frankly I don't think it's all that useful
The 'Open Connection' wizard has a disproportionate amount of code
devoted to this feature, but I don't think it's useful or worth
maintaining, so let's drop it
I've never heard of any other applications having support for using
mDNS to detect libvirtd instances. Though it is theoretically possible
something exists out there, it is clearly going to be a niche use case
in the virt ecosystem as a whole.
By removing avahi integration we can cut down the dependency chain for
the basic libvirtd install and reduce our code maint burden.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we added the seclabels to the schema we can test that they are
parsed and formatted correctly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Allow using seclabels the same way as disk images allow it. Currently
the snapshot code copies the seclabels from the original image if no
seclabel is provided. Also there's no code change required as the
snapshot XML parser actually uses parts of the disk parser thus
seclabels are already parsed and formatted and even applied thus this is
just a formalization of our support for this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.
Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Always assume JSON monitor was requested, since all the callers
pass true anyway.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
No reason not to be consistent with the user-visible value.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using 8 hex digits all the time, regardless of whether the
actual value can fit in fewer, makes it more obvious to the
user what the limits are.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case shows that we now reject invalid spapr-vio
addresses.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we no longer use that functionality we can also drop the tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we no longer support testing HMP monitor,
the json field is pointless.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We return success when running this function for either non-JSON monitor
testing or guest agent testing.
However we no longer test HMP monitor and we do not try to validate
the guest agent interaction.
Drop the test->json check and report a proper error if someone tries
to run this function for the guest agent without properly wiring it up.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The QMP monitor only uses a newline to separate lines,
while HMP and the guest agent also use a carriage return.
In preparation to dropping support for testing HMP interaction,
only skip the carriage return if we're dealing with the guest agent,
removing the need to check the 'json' field.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Update the capabilities from a non-upstream version (9c70209b63 is not
in qemu.git) to qemu upstream commit 33d6099906 (2019/06/18) so that we
get the QMP schema 'features' field support and are able to detect that
the 'file' block backend supports dynamic auto-read-only.
Note that I've rebuilt this on a machine with a more modern kernel and
microcode which exposes e.g. the recent CPU bug mitigations, thus I
opted to keep the CPU changes rather than trying to do a franken-caps
by updating only the output of query-qmp-schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
It was never implemented or used for anything else anyway. Mainly
because it uses CPUID features bits. The function is renamed as
qemuMonitorGetGuestCPUx86 to make this explicit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We used type=full expansion on the result of previous type=static
expansion to get all possible spellings of CPU features. Since we can
now translate the QEMU's canonical names to our names, we can drop this
magic and do only type=static CPU model expansion.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By default query-cpu-model-expansion only reports canonical names of all
CPU features. We do some magic and call the command twice to get all
possible spellings of the features, but being able to consume canonical
names will allow us to drop this magic.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When building QEMU command line, we should use the preferred spelling of
each CPU feature without relying on compatibility aliases (which may be
removed at some point).
The "unavailable-features" CPU property is used as a witness for the
correct names of the features in our translation table.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way we call query-cpu-model-expansion will rely on some capabilities
bits. Let's make sure all capabilities are set before probing host CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It is similar to "filtered-features" property, which reports CPUID bits
corresponding to disabled features, but more general. The
"unavailable-features" property supports both CPUID and MSR features by
listing their names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We will use it to check whether QEMU supports a specific CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This should cover all CPU features for which QEMU prefers spelling that
differs from the one used by libvirt.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Newer QEMU will translate the feature names to their canonical names so
4.0.0 is the last one which produces the results we currently have in
*-latest.args.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Normal CPU features use modern -cpu ...,feature=on|off syntax when
available, but kvm features kept using the old +feature or -feature.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These test check all kvm CPU features that could be passed to the -cpu
option by libvirt.
The 2.7.0 version is the last one for which we use +|-feature syntax for
CPU features, while feature=on|off is used with newer versions. This
is visible in the following patch which changes only the *-latest.args
files.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Hosts for rbd are ceph monitor daemons. These have fixed IP addresses,
so they are often referenced by IP rather than hostname for
convenience, or to avoid relying on DNS. Using IPv4 addresses as the
host name works already, but IPv6 addresses require rbd-specific
escaping because the colon is used as an option separator in the
string passed to librados.
Escape these colons, and enclose the IPv6 address in square brackets
so it is distinguished from the port, which is currently mandatory.
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The portid will be the UUID of the virNetworkPort object associated
with the network interface when a guest is running.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a virNetworkPortDefPtr struct to represent the data associated
with a virtual network port. Add APIs for parsing/formatting XML docs
with the data.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The domain conf actual network def stores a <class id='3'/> element
separately from the <bandwidth>. The class ID should really just be
an attribute on the <bandwidth> element. We can't change existing
XML, and this isn't visible to users since it is internal XML only.
When we expose the new network port XML to users though, we should
get the design right.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no obvious benefit in putting the escaped message
back into msg while tmp holds the original message.
Remove the assignment and use 'tmp' directly'.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Now that all the callers call qemuMonitorTestNew with json=true,
remove the argument and always assume JSON.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The only user of the qemuMonitorTestNewSimple macro is using JSON.
Always pass 'true' to qemuMonitorTestNew and remove the 'json'
argument.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
At this point, all test programs that use qemu_LDADDS also
use LDADDS, so we can remove a bunch of repetition by simply
including the latter in the former.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We optionally include QEMU and LXC support in this test and
depending on which is enabled (if either is enabled at all) we
need to link in different objects.
Right now we implicitly depend on the fact that qemu_LDADDS is
empty when QEMU is not enabled to get the correct set of objects,
but it's better to be explicit about it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We want all test programs using qemu_LDADDS to also use LDADDS,
and cputest is the only existing exception.
We can't just replace GNULIB_LIBS with LDADDS though, even though
the latter is a superset of the former, because that would result
in a linking error due to including the same object twice:
/usr/bin/ld:
../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141:
multiple definition of `libvirt_object_new_semaphore';
../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141:
first defined here
To work around this, we include both qemu_LDADDS and LDADDS when
QEMU support is enabled, and just LDADDS otherwise.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
When specifying extra params for spcie TLS verification, it's necessary
to pass a weird URI to it. Let's add a test for this case where the TLS
string contains a space.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Determine whether the test has failed after running all the cases so
that we don't need to rerun it multiple times to see all problems.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use VIR_TEST_VERBOSE instead. This fixes the following syntax check
problem:
tests/qemumonitorjsontest.c:1409: virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared");
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The upcoming virDomainBackup() API needs to take advantage of the
ability to expose a bitmap as part of nbd-server-add for a pull-mode
backup (this is the recently-added QEMU_CAPS_NBD_BITMAP capability).
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The upcoming virDomainBackup() API needs to take advantage of various
qcow2 bitmap manipulations as the basis to virDomainCheckpoints and
incremental backups. Add four functions to expose
block-dirty-bitmap-{add,enable,disable,merge} (this is the
recently-added QEMU_CAPS_BITMAP_MERGE capability).
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Add two capabilities for testing features required for the upcoming
virDomainBackupBegin: use block-dirty-bitmap-merge as the generic
witness of bitmap support needed for checkpoints (since all of the
bitmap management functionalities were finalized in the same qemu 4.0
release), and the bitmap parameter to nbd-server-add for pull-mode
backup support. Even though both capabilities are likely to be
present or absent together (that is, it is unlikely to encounter a
qemu that backports only one of the two), it still makes sense to keep
two capabilities as the two uses are orthogonal (full backups don't
require checkpoints, push mode backups don't require NBD bitmap
support, and checkpoints can be used for more than just incremental
backups).
Existing code is not affected by the new capabilities.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Migration always uses a TCP socket for NBD servers, because we don't
support same-host migration. But upcoming pull-mode incremental backup
needs to also support a Unix socket, for retrieving the backup from
the same host. Support this by plumbing virStorageNetHostDef through
the monitor calls, since that is a nice reusable struct that can track
both TCP and Unix sockets.
Update qemumonitorjsontest to verify both forms of the QMP command.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Time to remove the cleanup labels rendered useless in the previous
patch. There are still plenty of other tests that could be further
simplified, but I've already spent enough time in this file for now.
Signed-off-by: Eric Blake <eblake@redhat.com>
The DO_TEST() macro in qemumonitorjsontest.c was not passing the
schema through, which meant that we were not validating any of those
tests for correct usage according to the schema.
In the process of mechanically altering tests to pass the schema
through, use VIR_AUTOPTR on all of the affected test instances. The
next patch will do some further cleanups that it exposes.
Tested by using this hack, where the test mistakenly passed pre-patch,
but correctly diagnosed the garbage post-patch:
| diff --git i/src/qemu/qemu_monitor_json.c w/src/qemu/qemu_monitor_json.c
| index 53a7de8b77..86d8450814 100644
| --- i/src/qemu/qemu_monitor_json.c
| +++ w/src/qemu/qemu_monitor_json.c
| @@ -1532,7 +1532,8 @@ qemuMonitorJSONGetStatus(qemuMonitorPtr mon,
| if (reason)
| *reason = VIR_DOMAIN_PAUSED_UNKNOWN;
|
| - if (!(cmd = qemuMonitorJSONMakeCommand("query-status", NULL)))
| + if (!(cmd = qemuMonitorJSONMakeCommand("query-status",
| + "s:garbage", "foo", NULL)))
| return -1;
|
| if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0)
Suggested-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Simplify the GEN_TEST_FUNC() and target of the DO_TEST_SIMPLE() macros
by using autoptr support.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Upcoming tests are going to use VIR_AUTOPTR to simplify test cleanup.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Pass in the schema since it works with the 'file' test now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Pass in the schema data from the caller if QMP schema testing is
desired.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
In case when we are testing a QMP command we can try to schema check it
so that we catch inconsistencies.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The qemuTestParseCapabilitiesArch call would eventually lead to the host
CPU being probed via virCPUGetHost. Let's divert this to a mocked
version already used by the qemuxml2argvtest.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The function is renamed as virQEMUCapsProbeHostCPU and it does not get
the list of allowed CPU models from qemuCaps anymore. This is
responsibility is moved to the caller. The result is just a very thin
wrapper around virCPUGetHost mostly required mocking in tests.
The generic function is used in place of a direct call to virCPUGetHost
in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally
probe host CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1426162
Turns out, some aarch64 systems have SMBIOS info. That means we
can use dmidecode to fetch some information. If that fails, fall
back to the old behaviour.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There's nothing x86 specific about this function. Rename the
function so that it has DMI suffix which enables it to be reused
on different arches (as using X86 from say ARM would look
suspicious).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This test case uses (anonimized) data pulled from a
GIGABYTE R120-T34 server.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
We have a single mock dmidecode script right now, but we're
going to add another one soon, so we need to make sure its
name contains the test case name as a prefix, just like we
already do with all data files.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
SMMUv3 is an IOMMU implementation for ARM virt guests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability can be used to figure out whether the
QEMU binary at hand supports the machine type property
we need in order to enable SMMUv3 IOMMU support.
Unfortunately we can't avoid probing the RISC-V binaries
along with the ARM ones, since both architectures have
their own 'virt' machine type.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Creating firewall rules for the virtual networks causes the kernel to
load the conntrack module. This imposes a significant performance
penalty on Linux network traffic. Thus we want to only take that hit if
we actually have virtual networks running.
We need to create global firewall rules during startup in order to
"upgrade" rules for any running networks created by older libvirt.
If no running networks are present though, we can safely delay setup
until the time we actually start a network.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Device validation should not have to wait until command line
generation time. Moving the code to a separate function also
allows us to avoid some unnecessary repetition.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make sure validation is working as intended by trying to use
Intel IOMMU with the i440fx machine type, though we know it's
a q35-only feature, and expecting an error to be returned.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can drop the intel-iommu-machine test case while doing so,
since it is supposed to showcase how we generate different
command lines for older QEMU versions and we can do that
using a single input file now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove a bunch of irrelevant devices and make sure all input
files explicitly opt out of USB controllers: the latter change
will help later, when we start using DO_TEST_CAPS_*().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the 'shallow' and 'reuse' flags as booleans rather than passing
in flags and constructing them in irrelevant APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the 'shallow' flag as a boolean argument rather than passing
in flags and constructing them in irrelevant APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If an FD is passed into a child using:
virCommandPassFD(cmd, fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT);
then the parent should refrain from touching @fd thereafter. This
is even documented in virCommandPassFD() comment. The reason is
that either at virCommandRun()/virCommandRunAsync() or
virCommandFree() time the @fd will be closed. Closing it earlier,
e.g. right after virCommandPassFD() call might result in
undesired results. Another thread might open a file and receive
the same FD which is then unexpectedly closed by virCommandFree()
or virCommandRun().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since we know the full list of machine types supported
by the QEMU binary when probing machine type properties,
we can save some work (and eventually test suite churn,
as more architecture-specific machine types need to be
probed) by only probing machines that we know exist.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that we're probing machine type properties using the
latest machine type rather than the "spapr-machine" parent,
we can finally discover properties that are not available
on all machine types.
This commit refreshes replies for QEMU 4.0.0 as well as
3.1.0 to show not only that we're actually discovering new
machine type properties this way, but also that the number
of available machine type properties increases with each
subsequent QEMU release.
If qom-list-properties had been available in QEMU 2.10.0,
we could now drop the explicit version number checks for
the QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT and
QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT capabilities, but
unfortunately it wasn't, so we have to keep them around
still.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
