Tests testVirPCIVPDReadVPDBytes and testVirPCIVPDParseFullVPDInvalid
failed to properly close open fildescriptors in some cases. Let's fix it
by switching to VIR_AUTOCLOSE in the whole file.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the <loader> had an explicit readonly='no' attribute we
accidentally still marked the plfash as readonly due to the
bad conversion from virTristateBool to bool. This was missed
because the test cases run with no capabilities set and thus
are validated the -drive approach for pflash configuration,
not the -blockdev approach.
This affected the following config:
<os>
<loader readonly='no' type='pflash'>/var/lib/libvirt/qemu/nvram/test-bios.fd</loader>
</os>
for the sake of completeness, we also add a test XML config
with no readonly attribute at all, to demonstrate that the
default for pflash is intended to be r/w.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This change was generated using the following spatch:
@ rule1 @
expression a;
identifier f;
@@
<...
- f(*a);
... when != a;
- *a = NULL;
+ g_clear_pointer(a, f);
...>
@ rule2 @
expression a;
identifier f;
@@
<...
- f(a);
... when != a;
- a = NULL;
+ g_clear_pointer(&a, f);
...>
Then, I left some of the changes out, like tools/nss/ (which
doesn't link with glib) and put back a comment in
qemuBlockJobProcessEventCompletedActiveCommit() which coccinelle
decided to remove (I have no idea why).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert all code using the 'QOM_CPU_PATH' macro to accept the QOM path
as an argument.
For now the new helper for fetching the path 'qemuProcessGetVCPUQOMPath'
will always return the same hard-coded value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the parent address is part of the mdev nodedev name lets expose the
internally available parent address in the XML.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SmartNIC DPUs may not expose some privileged eswitch operations
to the hypervisor hosts. For example, this happens with Bluefield
devices running in the ECPF (default) mode for security reasons. While
VF MAC address programming is possible via an RTM_SETLINK operation,
trying to set a VLAN ID in the same operation will fail with EPERM.
The equivalent ip link commands below provide an illustration:
1. This works:
sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe
2. Setting (or clearing) a VLAN fails with EPERM:
sudo ip link set enp130s0f0 vf 2 vlan 0
RTNETLINK answers: Operation not permitted
3. This is what Libvirt attempts to do today (when trying to clear a
VF VLAN at the same time as programming a VF MAC).
sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe
RTNETLINK answers: Operation not permitted
If setting an explicit VLAN ID results in an EPERM, clearing a VLAN
(setting a VLAN ID to 0) can be handled gracefully by ignoring the
EPERM error with the rationale being that if we cannot set this state
in the first place, we cannot clear it either.
In order to keep explicit clearing of VLAN ID working as it used to
be passing a NULL pointer for VLAN ID is used.
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There should be a way to show no intent in programming a VLAN at all
(including clearing it). This allows handling error conditions
differently when VLAN clearing is explicit (vlan id == 0) vs implicit
(vlanid == NULL - try to clear it if possible).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This has a benefit of being able to handle error codes for those
operations separately which is useful when drivers allow setting a MAC
address but do not allow setting a VLAN (which is the case with some
SmartNIC DPUs).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The XML-to-XML test validates that we don't accidentally copy the
isa-debug <serial> into a <console>.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a perfectly valid configuration that we need to keep
working, so add test coverage for it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, memory device (def->mems) part of cmd line is
generated before any controller. In majority of cases it doesn't
matter because neither of memory devices live on a bus that's
created by an exposed controller (e.g. there's no DIMM
controller, at least not exposed). Except for virtio-mem and
virtio-pmem, which do have a PCI address. And if it so happens
that the device goes onto non-default bus (pci.0) starting such
guest fails, because the controller that creates the desired bus
wasn't processed yet. QEMU processes arguments in order.
For instance, if virtio-mem has address with bus='0x01' QEMU
refuses to start with the following message:
Bus 'pci.1' not found
Similarly for virtio-pmem. I've successfully tested migration and
changing the order does not affect migration stream.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2047271
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Inside the testPCIVPDResourceCustomCompareIndex() function we
have two variables @a and @b, both marked as g_autoptr(). Then,
towards the end of the function b->value is freed and set to
a->value. This is to make sure
virPCIVPDResourceCustomCompareIndex() works correctly even if
->value member is the same for both arguments.
Nevertheless, if the function returns anything else than 0 then
the control executes subsequent return statement and since
b->value points to the very same string as a->value a double free
will occur. Avoid this by setting b->value to NULL explicitly,
just like we are already doing for the successful path.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
There are a few places where a variable is VIR_FREE()-d and then
explicitly set to NULL. This is not necessary since VIR_FREE()
does that for us.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Since its introduction in
commit 907a39e735
Add a test suite for validating SELinux labelling
this function did not return NULL on OOM.
Since we abort on OOM now, switch testSELinuxMungePath to void,
return NULL explicitly on XML parsing failure and remove
the (now pointless) cleanup label.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reporting hv-* properties properly requires hv to be enabled,
see qemu commit 071ce4b03b.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are a some scenarios in which we want to prealloc guest
memory (e.g. when requested in domain XML, when using hugepages,
etc.). With 'regular' <memory/> models (like 'dimm', 'nvdimm' or
'virtio-pmem') or regular guest memory it is corresponding
memory-backend-* object that ends up with .prealloc attribute
set. And that's desired because neither of those devices can
change its size on the fly. However, with virtio-mem model things
are a bit different. While one can set .prealloc attribute on
corresponding memory-backend-* object it doesn't make much sense,
because virtio-mem can inflate/deflate on the fly, i.e. change
how big of a portion of the memory-backend-* object is exposed to
the guest. For instance, from a say 4GiB module only a half can
be exposed to the guest. Therefore, it doesn't make much sense to
preallocate whole 4GiB and keep them allocated. But we still want
the part exposed to the guest preallocated (when conditions
described at the beginning are met).
Having said that, with new enough QEMU the virtio-mem-pci device
gained new attribute ".prealloc" which instructs the device to
talk to the memory backend object and allocate only the requested
portion of memory.
Now, that our algorithm for setting .prealloc was isolated in a
single function, the function can be called when constructing cmd
line for virtio-mem-pci device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This new capability tracks whether virtio-mem device is capable
of memory preallocation, which is detected by the device having
.prealloc attribute.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to use a hardcoded list of capabilities because we don't
yet have proper replies files obtained from QEMU running on actual
macOS machines.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Brad Laue <brad@brad-x.com>
Tested-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The new DO_TEST_MACOS() macro makes it possible to create test
cases that verify the behavior of libvirt on a macOS machine
with HVF support available.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Brad Laue <brad@brad-x.com>
Tested-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This exposes a couple of macOS-specific variants of existing
APIs, which can be used when implementing test programs and
result in HVF support being advertised.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Brad Laue <brad@brad-x.com>
Tested-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This new enumeration provides a way to specify the host OS
that a specific test case expects. The default is Linux, which
has been the implicit host OS until now; when Linux is selected
as the host OS, KVM support is advertised in capabilies data
exposed to test cases.
This commit doesn't result in any functional change, and simply
sets the stage for introducing macOS host OS support later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Brad Laue <brad@brad-x.com>
Tested-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When trying to attach vhost-user-blk device to virtual machine using
qemu < 4.2 libvirt would mistakenly add a scsi=off parameter, which is
not supported by qemu.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/265
Signed-off-by: shenjiatong <yshxxsjt715@gmail.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
With qemu versions prior to qemu-5.0 we'll format 'scsi=off' for
virtio-blk disks, but also for vhost-user-blk. This is a bug as it's not
supported.
Add a test case to show that wrong configuration is generated by adding
running 'disk-vhostuser' test case on capabilities from qemu-4.2.
For this to be possible it's required to enable shared memory via NUMA
configuration as old QEMU's don't allow configuration of the default
memory backend. This is achieved by adding a copy of the
'disk-vhostuser' XML with NUMA enabled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
After previous cleanups, the virDomainNetDefParseXML() function
uses a mixture of virXMLProp*() and the old virXMLPropString() +
virXXXTypeFromString() patterns. Rework it so that virXMLProp*()
is used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update existing ppc64 6.2 caps to match what was released in QEMU 6.2.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Changes in all 'ppc64-latest.ags' files were needed due to the
JSONification of command line devices.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since there's no capability to check now, we can simply move the
formatting of 'max_outputs' earlier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both are supported by qemu-2.11 and later, so we don't have to check for
them explicitly.
Note that QXL is supported only on x86_64, thus on other arches only the
capability for 'virtio-gpu' is removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both the QXL video device and 'virtio' video device support
'max_outputs' in all qemu versions libvirt supports. This means we no
longer have to check the QEMU_CAPS_QXL_MAX_OUTPUTS and
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was only used to construct the hash key for the (now removed)
shared devices in the qemu driver.
Remove it and its mocking.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
No kernels supported by upstream libvirt have the feature.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This device was virtio 1.0-only so adding the (non-)transitional model
did not make sense and it was only present in QEMU 4.0.
Report a validation error for both of the users that will ever hit this
code path.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that looking up dnsmasq is handled/mocked we can start
checking whether dnsmasq capabilities were built successfully and
error out if that wasn't the case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
DISCLAIMER: dnsmasq capabilities are empty as of v8.0.0-rc1~145.
In a real environment the dnsmasq capabilities are constructed
using dnsmasqCapsNewFromBinary(). We also have
dnsmasqCapsNewFromBuffer() to bypass checks that real code is
doing and just get capabilities object. The latter is used from
test suite.
However, with a little bit of mocking we can test the real life
code. All that's needed is to simulate dnsmasq's output for
--version and --help and mock a stat() that's done in
dnsmasqCapsRefreshInternal().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
While it's true that our virCommand subsystem is happy with
non-absolute paths, the dnsmasq capability code is not. It stores
the path to dnsmasq within and makes it accessible via
dnsmasqCapsGetBinaryPath(). While strictly speaking no caller
necessarily needs canonicalized path, let's find dnsmasq once and
cache the result.
Therefore, when constructing the capabilities structure look up
the binary path. If DNSMASQ already contains an absolute path
then virFindFileInPath() will simply return a copy.
With this code in place, the virFileIsExecutable() check can be
removed from dnsmasqCapsRefreshInternal() because
virFindFileInPath() already made sure the binary is executable.
But introducing virFindFileInPath() means we have to mock it in
test suite because dnsmasqCaps are created in
networkxml2conftest.
Moreover, we don't need to check for dnsmasq in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We don't query any capabilities of dnsmasq. We are only
interested in dnsmasq's version (obtained via 'dnsmasq
--version'). Therefore, there's no point in running 'dnsmasq
--help'. Its output is not processed even.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The dnsmasqCaps type has its own cleanup function defined and
ready to use via g_autoptr(). Use automatic cleanup instead of
an explicit one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If a test binary is executed with an argument then usage
information is printed out (that no arguments are accepted and
what environment variables affect execution). The string is
printed onto stderr but it is not terminated with a newline
character producing not so nice output.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Now that qemu fixed device unplug when JSON syntax is used with -device
we can re-enable the feature.
Since the old capability string representation is condemned by
suggesting filtering it as a workaround we must introduce a new string.
To achieve this the original capability position is renamed to
X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the
original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having
to change the rest of the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update to commit v6.2.0-874-g1cd2ad11d3
Notable changes are:
- added flag noting that use of JSON syntax for -device was fixed
- 'dbus' backend for graphics and character devices added
- virtio-mem added 'node' property
- 'clusters' added to CPU topology
- 'open-timeout' property for NBD protocol backend
- 'wheel-left' and 'wheel-right' event types for 'input-send-event'
- increased default resolution to '1280x800' on 'virtio-gpu'
- SGX property 'section-size' changed to 'sections' incompatibly
(unused luckily)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The machine type doesn't change the test result and prevents tests being
changed every time we are about to update real capabilities to a new
qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two tests currently that simulate QMP talk:
qemucapabilitiestest and qemuhotplugtest. In both cases they
check whether currently executed command is the one for which
reply was provided. If not an error message is reported. However,
the error message contains only the actual command and not the
expected one. This makes it harder to navigate through .replies
files.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
VM XML accepts target.port but this does not get passed while
building the QEMU command line for this VM.
Signed-off-by: Divya Garg <divya.garg@nutanix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit takes care of following cases:
-> Check availability of requested ports.
->The total number of requested ports should not be more than
VIR_MAX_ISA_SERIAL_PORTS.
->The ports requested should be less than VIR_MAX_ISA_SERIAL_PORTS.
->VIR_MAX_ISA_SERIAL_PORTS should correspond to MAX_ISA_SERIAL_PORTS
specified in QEMU code commit def337ffda34d331404bd7f1a42726b71500df22.
-> Prevent duplicate device assignments to the same port.
-> In case no ports are provided in the XML, this patch scans the list of unused
isa-serial indices to automatically assign available ports for this VM.
Signed-off-by: Divya Garg <divya.garg@nutanix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When -device is configured via JSON a bug [1] is triggered in qemu were
the DEVICE_DELETED event for the removal of the device frontend is no
longer delivered to libvirt. Without the DEVICE_DELETED event we don't
remove the corresponding entries in the VM XML.
Until qemu will be fixed we must stop using the JSON syntax for -device.
This patch removes the detection of the capability. The capability is
used only during startup of a fresh VM so we don't need to consider any
compaitibility steps for existing VMs.
For users who wish to use 'libvirt-7.9' and 'libvirt-7.10' with
'qemu-6.2' there are two possible workarounds:
- filter out the 'device.json' qemu capability '/etc/libvirt/qemu.conf':
capability_filters = [ "device.json" ]
- filter out the 'device.json' qemu capability via qemu namespace XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
[...]
<qemu:capabilities>
<qemu:del capability='device.json'/>
</qemu:capabilities>
</domain>
We must never again use the same capability name as we are now
instructing users to filter it as a workaround so once qemu is fixed
we'll need to pick a new capability value for it.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2036669
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035237
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Until now we did 2 weird things when inserting the qemuCaps used for
individual test cases into the capability cache:
1) we inserted the same caps for all emulators
2) we always (expensively) copied them
Now when real capabilities are used we don't touch them at all just
simply inser them. This allows us one big optimization, by trading a
copy for just a virObjectRef as we can borrow the caps object to the
cache.
For fake caps we still copy them as we insert the fake machine types
into them, but second big optimization is to insert the capabilities
only for the architecture they belong to.
Additionally this commit also ensures that all other entries in the
cache for the binary are poisoned by empty caps so that it's obvious
that the test is doing the right thing.
Apart from this making actually more sense this shaves off more than 40%
of runtime from qemuxml2argvtest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Emulator binary change is needed to use the latest caps properly. The
comment is no longer needed, the expected error is recorded in the 'err'
file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Also ensure that the emulator and architecture are correct for
DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As demonstrated by the qemuxml2xmltest DO_TEST_CAPS_LATEST data based on
the 'x86-kvm-32-on-64' test case the post parse CPU selection code which
fills in the CPU into the definition does not have exactly the same
logic as we used to have when the cpu model was picked when formatting
the commandline.
Change the qemuxml2argv test to use DO_TEST_CAPS_LATEST too as it
doesn't really make sense to test this on fake data.
In addition to 'latest' versions, this also adds second invocation
locked to qemu-4.1.0 which demonstrates the old behaviour.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fake capabilities are inserted twice, as in a few tests the architecture
is not present in the XML (testing filling in of the architecture).
Since we already know which architecture will be picked we don't need to
be adding the capabilities twice.
This doesn't impact the tests as they use the same approach to determine
the default arch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will modify how we populate the capability cache in
tests to be more sane. This also means that the emulator binary and
architecture used in the test files using real capabilities must match
what the real capabilities have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will modify how we populate the capability cache in
tests to be more saner. This also means that the emulator binary and
architecture used in the test files using real capabilities must match
what the real capabilities have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The specific machine type is not important for the test. We can use 'pc'
instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuxml2argv invocation of some tests used DO_TEST_CAPS_LATEST while
the qemuxml2xmltest invocation uses fake caps. Unify them on
DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since introduction in fc03eb53c0 there wasn't a qemuxml2argv
version. As we are touching the files convert them to
DO_TEST_CAPS_LATEST directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to commit 5222256849 the test case was added to verify that
the '<address>' element is covered by the schema. The test was not
registered for qemuxml2argvtest though. We can use 'net-server' instead
as it has the same type. On the other hand that one was not registered
for qemuxml2xmltest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's nothing special about the tests requiring to use very old
machine types. Most usage is cargo-culted from other tests. Switch all
the tests to use 'pc' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For tests with fake capabilities we fill in a bunch of machine types
which the tests might use. For now there's a random collection of
machine types which are not actually used. Purge the unused ones for
non-x86 machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The two test cases were added to avoid regressions such as fixed in
17dff35848. Nowadays the code is much simpler and any Q35 machine
will trigger the explicit FDC.
Remove the '2.11' machine type version and turn the '2.9' version into a
generic q35 machine.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All the fd-passing setup of chardevs which this hack meant to disable
was moved to the host-preparation phase which is skipped for formatting
of non-real commandlines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
And make callers check the return value as well. This helps error out early for
invalid environment variables.
That is desirable because it could lead to deadlocks. This can happen when
resetting logging after fork() reports translated errors because gettext
functions are not reentrant. Well, it is not limited to resetting logging after
fork(), it can be any translation at that phase, but parsing environment
variables is easy to make fail on purpose to show the result, it can also happen
just due to a typo.
Before this commit it is possible to deadlock the daemon on startup
with something like:
LIBVIRT_LOG_FILTERS='1:*' LIBVIRT_LOG_OUTPUTS=1:stdout libvirtd
where filters are used to enable more logging and hence make the race less rare
and outputs are set to invalid
Combined with the previous patches this changes
the following from:
...
<deadlock>
to:
...
libvirtd: initialisation failed
The error message is improved in future commits and is also possible thanks to
this patch.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Set a launch secret in guest memory using the sev-inject-launch-secret
QMP API. Only supported with qemu >= 6.0.0 and SEV-enabled guests in a
paused state.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The 'sev-inject-launch-secret' qmp command is only available with
qemu >= 6.0.0. Introduce a capability for sev-inject-launch-secret.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There's no real difference between input and output XMLs for
kvm-features and kvm-features-off test cases. Do what we usually
do in such case - turn the output file into a symlink of the
input file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Make the tpm-*.xml files symlinks to their respective input XMLs
from qemuxml2argvdata/ directory. Neither of the XMLs relies on
autofill of any TPM data.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We already have the input xml because of xml2arg test. However,
the corresponding xml2xml test case is missing. Make the expected
XML a symlink to the input XML and clean the latter up a bit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'qemucapabilitiesnumbering' tool now replaces the role of this
script and provides way to programmatically modify the replies file on
top.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tool is assembled from individual bits used for tests and actual
capturing of the replies files. The tool ensures correct numbering and
formatting of entries.
In normal usage mode it masks as a test which validates formatting and
numbering of the tests/qemucapabilitiesdata/*.replies files. This tool
was actually used to produce commits 096ac87a1a and aa21615ccb.
In case a manual modification of the replies file is needed the
'modify()' function provides a convenient way to do programatic
modification of the caps file.
As an example the modify() function has commented-out code which
provides a basic scaffold to do modifications along with a how-to.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make the parser reusable by extracting it and making it parse into
command,reply tuples.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We now know exactly which GLib version we need to depend on
for the workaround to no longer be necessary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
All of these are affected by the same issue as the ones that
we're already skipping during this specific time interval.
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Will keep things reasonable as we perform further code
movements.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
With 'g_strdup' not needing error handling we can ask callers to pass a
copy of the string which will be adopted by the JSON value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
QCOW2 images now support 'extended_l2' which splits the default clusters
into 32 subcluster allocation units. This allows the allocation units to
be smaller without increasing the size of L2 table too much and thus also
the cache requirements for holding the full L2 table in memory.
Unfortunately it's incompatible with qemu versions older than 5.2 thus
can't be used as default.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two functions that take variable arguments:
vshTableNew() and vshTableRowAppend(). Both expect the list of
arguments to be NULL terminated. Annotate them with
G_GNUC_NULL_TERMINATED to enable compile time check for this.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In testVshTableNew() we test whether vshTableNew(NULL) allocates
a table. This is expected to fail (and return NULL), because
passing nothing but NULL to vshTableNew() is viewed as error.
Nevertheless, if vshTableNew() did not fail and returned an
allocated table it would be leaked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After previous commit, it's no longer possible to change nodeset
for strict numatune. Therefore, we can start generating
host-nodes onto command line again.
This partially reverts d73265af6e.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Under the qemucapabilitiesdata we have a replies file for
QEMU-3.0.0.ppc64. At least we think so. In fact, the file
contains replies from a development snapshot release that
predates 3.0.0 (specifically it's v2.12.0-1689-g518d23a) and as
such does not reflect any change that was made to QEMU after the
snapshot and before the official relase. One of such changes was
renaming 'exit-preconfig' command to 'x-exit-preconfig' (QEMU
commit v3.0.0-rc1~21^2~3). Ideally, we would just regenerate
capabilities using the official release but since this is a PPC64
machine and pretty old version anyway let's just fix the command
name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Set the kernel-hashes property on the sev-guest object if the config
asked for it explicitly. While QEMU machine types currently default to
having this setting off, it is not guaranteed to remain this way.
We can't assume that the QEMU capabilities were generated on an AMD host
with SEV, so we must force set the QEMU_CAPS_SEV_GUEST. This also means
that the 'sev' info in the qemuCaps struct might be NULL, but this is
harmless from POV of testing the CLI generator.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the QEMU tests a test can either use an explicitly listed set of
capabilities, or can request those matching a particular QEMU
version. Sometimes it is desirable to be able to list extra caps
on top of those implied by a particular version.
This is useful, for example, when QEMU won't report certain features
unless it was run on particular hardware or kernels, and those were
not used when a caps snapshot was imported to the libvirt source tree.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This sev-guest object property indicates whether QEMU should
expose the kernel, ramdisk, cmdline hashes to the firmware
for measurement.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A recent code movement introduced a bug which reproduces only when there
are two disks on the same bus missing the target. Improve the test case
for the missing target test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu-6.2 is out, update the caps dump for the final time.
Notable changes:
- 'unstable' feature flag for various QMP schema entries
- 'aio-max-batch' iothread property
- 'kernel-hashes' knob for the 'sev-guest' object
- 'native-hotplug' of 'pcie-root-port' is now unstable again
- 'page-sampling/dirty-ring/dirty-bitmap' mode for 'calc-dirty-rate'
- 'toolsversion' field for the 'vmdk' disk format driver
- CPU changes resulting in 'core-capability' being present on the cpu
of the machine this dump was done on
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Different CPU generations have different limits on the number
of SEV/SEV-ES guests that can be run. Since both limits come
from the same overall set, there is typically also BIOS config
to set the tradeoff betweeen SEV and SEV-ES guest limits.
This is important information to expose for a mgmt application
scheduling guests to hosts.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There are limits on the number of SEV/SEV-ES guests that can
be run on machines, which may be influenced by firmware
settings. This is important to expose to users.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We're only returning the set of fields needed to perform an
attestation, per the SEV API docs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
