Add capabilities based on a dump from x86_64 host running Fedora for the
qemu-system-arm binary.
The test dump will be used for illustration of USB controller model
selection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Allow using armv7l arch in a capability dump.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Document the reality that some dumps were faked for purpose of testing
corner cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Mention the new 'scripts/qemu-replies-tool.py'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This is guaranteed to keep failing even after loongarch64
support is introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This fails to be parsed because libvirt doesn't yet know about
the architecture, but thanks to the recent improvements this
is a merely a local failure rather than bringing everything
else down with it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are two memleaks inside of nodedevmdevctltest:
1) In the testCommandDryRunCallback() - when appending lines to
stdinbuf the pointer is overwritten without freeing the old
memory it pointed to.
2) In testMdevctlModify() the livecmd variable is reused and
since its marked as g_autoptr() the first use leaks.
Fixes: 582f27ff15
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implement the API functions in the node device driver by using mdevctl
modify with the options defined and live.
Instead of increasing the minimum mdevctl version to 1.3.0 in the spec
file to ensure support exists in mdevctl the support is dynamically
checked before using mdevctl.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The configuration of a defined mdev can be modified after the mdev is
started. The defined configuration and the active configuration can
therefore run out of sync. Handle this by storing the modifiable data
which is the mdev type and attributes in two separate active and
defined configurations. mdevctl supports with callout scripts to do an
attribute retrieval of started mdevs which is already implemented in
libvirt.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new test case checks whether we are handling NVDIMMs
correctly when checking for overlapping memory devices (see
previous commit). Without previous commit, this test case would
fail, yet it was produced in real life (at least the NVDIMM
part) and thus it is valid.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
It's not portable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The existing capabilities were generated against a build made
quite early in the QEMU 8.1.0 development cycle. Update them
to match the final release.
A notable effect of this is that the recently introduced
s390-usb-model test now passes instead of failing: QEMU 8.1.0
enables several new devices on s390x, including the qemu-xhci
USB controller.
There's a small amount of additional churn caused by the fact
that the machine on which I have generated these capabilities
is apparently slightly less fancy than the one used originally.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Show what happens when trying to use a specific type of USB
controller. This currently fails because the QEMU binary doesn't
include the necessary device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These tests currently cover the scenarios in which the guest
can end up with no USB controller, one of which is specific
to s390x. We are going to add more USB on s390x scenarios, so
a different naming convention is needed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Previously this test only tested the generated nbdkit command for the
top level disk source. Update it to test the generated commmands for all
sources in the chain.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'raw' driver without any special configuration is not needed and
creates overhead in qemu.
Stop using the 'raw' format driver in cases when it's not needed. A
special case when it is needed is for FD passed images with only a
single writable FD passed, where we need an overlay driver to properly
reflect the 'read-only' flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability is asserted when both block-stream and block-commit QMP
commands support the 'backing-mask-protocol' argument.
The argument causes qemu to record 'raw' as the backing file format in
case when a protocol node is used directly. This is needed to preserve
compatibility of images after a block-commit or block-pull libvirt
operation with older libvirt versions in case when we'll want to remove
the unneded 'raw' format drivers from the block graph.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update to 'v8.2.0-952-g14639717bf'.
Notable changes:
- 'backing-mask-protocol' feature added for block-commit and block-stream
- 'singlestep' mode dropped
- 'cmpccxadd' cpu feature became available
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unexport the function and 'struct qemuMonitorTestCommandReplyTuple' as
they are currently used only in tests/qemumonitortestutils.c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The test case was completely replaced by the 'qemu-replies-tool.py'
script in default mode.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The tool in the current shape functionally replaces
tests/qemucapabilitiesnumbering.c
It validates that the output '.replies' files conform to how we generate
them from qemu and also allows programmatic modification of the
'.replies' files if re-generation is not feasible any more.
The main advantage is that JSON objects are parsed into native python
types and thus the programatic modification is much more convenient.
The tool will be later extended to also do validation that we properly
handle the whole of QMP schema as well as help in reviewing the
differences in the .replies file after qemu updates.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
YAJL formats empty objects and arrays in a weird way:
{
"emptyarray": [
],
"emptyobject": {
}
}
We want to use empty lines to separate commands and replies as well as
be compatible with python's 'json.dump' method, thus we drop any
whitespace between array/object braces.
Adjust the two formatters which are used for capabilities and fix all
output files.
Note that the code is duplicated in qemucapabilitiesnumbering.c and
qemucapsprobemock.c, but later patches will replace
qemucapabilitiesnumbering.c by a python tool.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The "auto" SCSI controller model was introduced for use in the
ESX driver, but the QEMU driver doesn't reject the value.
Add a test case showing the behavior when such a configuration
is encountered.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Until now 'virPCIDeviceGetVPD' couldn't reallistically raise an error,
but that will change. Handle the errors by either resetting it if we'd
be ignoring it or forward it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function always succeeded and after the removal of programing error
checks doesn't even have a 'return false' case. Additionally one of the
tests in 'virpcivpdtest' tested that this function never failed on wrong
data. Embrace this logic and remove the return value and adjust logging
to VIR_DEBUG level to avoid spamming logs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a synthetic case which tests the behaviour if the 'ro' or 'rw'
struct members are uninitialized, basically excercising only a pointless
programming-error NULL check in 'virPCIVPDResourceUpdateKeyword' as real
usage does always pass a proper pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the callers pass NULL, so the NULL check is pointless. Remove it
an remove the return value.
The function is exported only for use in 'virpcivpdtest' thus marking
the arguments as NONNULL is unnecessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case excercises 'virPCIVPDParseVPDLargeResourceString' which is
also tested by other cases which parse the whole VPD block. Remove the
specific test case as it's not adding any additional value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The case checks only the 'virPCIVPDReadVPDBytes' which is also tested
multiple times via 'virPCIVPDParse' as it's used to read the data, thus
having a special case for this is pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modify the test data to validate '<>' and other characters.
Unfortunately the test suite doesn't have a proper end-to-end test, thus
we just add a XML->XML variant and also add data to the binary parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These are similar to the minimal cases that we just introduced,
but are intended to demonstrate what device or controller model
libvirt will choose when one is not provided by the user.
Note that we want both regular and ABI_UPDATE variants of the
various test cases because, in some cases, the behavior for new
guests is not the same as that for existing ones due to backward
compatibility concerns.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We have just added a number of test cases that supersede it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We currently have a single test case called "minimal", which
suffers from two big flaws:
* it's limited to the x86_64/pc machine type;
* it explicitly enables a number of devices.
Add several test cases, one for each of the architectures and
machine types that we have good support for.
Unlike the existing one, they're *really* minimal: no devices
or controllers at all are present in the input XML. So the new
test cases demonstrate exactly what devices and controller
libvirt will decide to add automatically.
Note that we want both regular and ABI_UPDATE variants of the
various test cases because, in some cases, the behavior for new
guests is not the same as that for existing ones due to backward
compatibility concerns.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This demonstrates that on aarch64, where a native panic device
doesn't exist, it's necessary for the user to specify the model
explicitly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For q35 guests, we normally add a USB controller by default,
but there's a scenario in which we can decide to skip it. Add
test coverage for it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we have an explicit test case for the feature in
genericxml2xmltest, we can drop a bunch of duplicated accidental
coverage from qemuxmlconftest.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We have a few cases in qemuxmlconftest that cover the ability
to set <title> and <description> for a guest as a side effect.
Introduce an explicit case for the functionality in
genericxml2xmltest, as it's not specific to the QEMU driver.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is pretty straightforward.
Resolves: https://issues.redhat.com/browse/RHEL-15316
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Starting from v8.2.0-rc0~74^2~2 QEMU has .dynamic-memslots
attribute for virtio-mem-pci device. Introduce a capability which
reflects that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute for virtio-mem-pci devices. When
turned on, it allows memory exposed to guest to be split into
multiple memslots and thus smaller memory footprint (see the
original commit for detailed explanation).
Therefore, introduce new <target/> attribute which will control
that QEMU knob.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are a number of cases in which we want to test both the
normal behavior and the ABI_UPDATE behavior for the same input
XML.
The way this is currently implemented is ad-hoc, and involves
symlinking the input XML as well as coming up with an
alternative name for the ABI_UPDATE variant: in most cases the
-abi-update suffix is added, but since this is not enforced
there are a couple of cases where we do something else instead.
To make things simpler and more consistent, implement the
naming convention at the macro level. This way, we no longer
need to create any symlinks for the input file, and the output
files are automatically named correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The input file is a symlink for the ppc64-usb-controller input
file, so the output files are identical as well. It's just an
unnecessary duplicate.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These values are currently unsupported for ssh disks, and in fact aren't
even parsed for ssh disks. So while this didn't result in any test
errors, we can remove them from the test input files.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
