The cpu commandline is identical with the '-latest' version so there's
no need for a separate case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test was showing that the 'blockdev' capability is properly added
although we didn't detect it yet. Unfortunately this test can't be
carried over once we bump minimum qemu version to qemu-4.2.
Make the test case future-proof by removing the qemu-4.0.0 version which
would become pointless and use only already deprecated capability flags
so that the test output does not change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested net device has the same syntax with latest qemu so there's no
need to have a version-locked test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu feature formatting doesn't change between the versions thus we
can just keep the '-latest' versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested feature doesn't change across versions so we can use the
modern testing infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The version-locked version of the test data is identical to the 'latest'
version so we can remove them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prior to qemu-3.2 we'd have to disable the 'pconfig' feature explicitly
which is no longer needed with new qemu. Remove the version locked to
qemu-3.1 as the 'latest' case sufficiently handles what we want to test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, a firmware configuration such as
<os firmware='efi'>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
</firmware>
</os>
will correctly pick a firmware that implements the Secure Boot
feature and initialize the NVRAM file so that it contains the
keys necessary to enforce the signing requirements. However, the
lack of a
<loader secure='yes'/>
element makes it possible for pflash writes to happen outside
of SMM mode. This means that the authenticated UEFI variables
where the keys are stored could potentially be overwritten by
malicious code running in the guest, thus making it possible to
circumvent Secure Boot.
To prevent that from happening, automatically turn on the
loader.secure feature whenever a firmware that implements Secure
Boot is chosen by the firmware autoselection logic. This is
identical to the way we already automatically enable SMM in such
a scenario.
Note that, while this is technically a guest-visible change, it
will not affect migration of existings VMs and will not prevent
legitimate guest code from running.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:
* we still want the path to the NVRAM file to be customizable;
* using <loader secure='yes'/> was how you would ask for a
firmware that implements the Secure Boot feature in the
original approach to firmware autoselection, so we want to
keep that working.
Anything else should result in a descriptive error.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This combination doesn't make sense and so the firmware
autoselection logic will not be able to find a suitable firmware,
but it's more user-friendly to report a detailed error upfront.
Note that this check would ideally happen in the validate phase,
but if we moved it there we would no longer be able to
automatically enable secure-boot when enrolled-keys=yes. Since
the combination never resulted in a working configuration, the
chances of this causing real-world VMs to disappear are
extremely low.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the lack of a <loader> element results in the <nvram>
element being completely ignored, but this is unnecessarily
limiting: even when firmware autoselection is in use, it should
be possible for the user to specify a custom path for the NVRAM
file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that some of these new tests are displaying incorrect or
suboptimal behavior. When we address those in upcoming patches,
this will be highlighted by changes in the test data.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This currently has not effect whatsoever, so it's just cluttering
the input files.
We're going to add specific handling for this scenario, as well
as a test case covering it, in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This does the opposite of
commit 392292cd99
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Wed Feb 23 12:45:51 2022 +0000
tests: don't use auto-generated NVRAM path in tests
in order to minimize input files.
We're going to add a test case specifically covering the use of
custom NVRAM paths with firmware autoselection in an upcoming
commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When testing firmware selection, we don't really care about any
of the hardware assigned to the VM, and in fact it's better to
keep it as minimal as possible to make sure that the focus
remains on the firmware bits.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Group all tests related to firmware selection together and give
them consistent names that leave room for further tests to be
added in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was introduced in
commit 5882064084
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Wed Feb 25 15:45:26 2015 +0100
tests: Add test for os interleaving
to ensure a recent change in the schema was behaving correctly.
Seven years later, it no longer seems very useful to keep it
around.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This simplifies the test data without negatively impacting test
coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The pci-bridge-many-disks test case is not related to firmware
handling at all, so we can trim it without losing any coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add an element to configure the thread pool size:
...
<binary>
<thread_pool size='16'/>
</binary>
...
https://bugzilla.redhat.com/show_bug.cgi?id=2072905
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As of v7.0.0-877-g70ac26b9e5 QEMU exposes its default event loop
for devices with no IOThread assigned as an QMP object. In the
very next commit (v7.0.0-878-g71ad4713cc) it was extended for
thread-pool-min and thread-pool-max attributes. Expose them under
new <defaultiothread/> element.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
At least in case of QEMU an IOThread is actually a pool of
threads (see iothread_set_aio_context_params() in QEMU's code
base). As such, it can have minimal and maximal number of worker
threads. Allow setting them in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Notable changes:
- Icelake-Client cpu model family removed:
"Icelake-Client-noTSX-x86_64-cpu"
"Icelake-Client-v1-x86_64-cpu"
"Icelake-Client-v2-x86_64-cpu"
"Icelake-Client-v3-x86_64-cpu"
"Icelake-Client-x86_64-cpu"
- 'zero-copy-send' migration feature added
- display 'sdl' qapified
- 'arch-lbr' cpu feature added
- new HyperV enlightenments:
'hv-tlbflush-ext'
'hv-tlbflush-direct'
'hv-emsr-bitmap'
'hv-xmm-input'
- 'none-machine' has two new properties:
- "boot" described as "Boot configuration"
- "memory" described as "Memory size configuration"
- 'igd-passthrough-isa-bridge' is now Xen-only
- CXL: Compute eXpress Link related devices:
"CXL"
"cxl-rp",
"cxl-type3",
"pxb-cxl",
"pxb-cxl-bus",
"pxb-cxl-host",
- 'dma-translation' feature of 'intel-iommu'
- 'vmcb-clean' cpu feature now migratable:
- possibly due to host kernel upgrade
- changes commandline generated for the 'cpu-host-model' case of
qemuxml2argvtest
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the newly added ARG_CAPS_HOST_CPU_MODEL to set which host CPU we
expect the test to use - the test should fail when using a POWER8 host
cpu but complete when using a POWER9 host cpu.
Two new macros were added because we will be adding similar tests in the
near future when adding support for the Power10 chip.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The USB device redirection works in a similar way as Spice. The
underlying 'dbus' channel is set to "org.qemu.usbredir" by default for
the client to identify the channel purpose (as specified in -display
dbus documentation).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Like a Spice port, a dbus serial must specify an associated channel name.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
By default, libvirt will start a private bus and tell QEMU to connect to
it. Instead, a D-Bus "address" to connect to can be specified, or the
p2p mode enabled.
D-Bus display works best with GL & a rendernode, which can be specified
with <gl> child element.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add support for the mode and add the corresponding qemuxml2argv test
case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'absolute' clock offset type has a 'start' attribute which is an
unix epoch timestamp to which the hardware clock is always set at start
of the VM.
This is useful if some VM needs to be kept set to an arbitrary time for
e.g. testing or working around broken software.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to always store the state of the feature in the
virDomainDef struct, otherwise
<smm state='off'/>
will incorrectly be interpreted as if the <smm> element was not
present.
Fixes: eeb94215b0
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This complements the existing smm=on tests. Looking at the output
files, one can immediately see how this case is currently not being
handled correctly. We're going to fix that in the next commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST() instead of hardcoding capabilities and
add the xml2xml part, which was missing; finally, rename it to
accomodate the complementary smm=off test that we're about to
introduce.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the block guarded by 'is_tap' boolean to the only place where
'is_tap' is set to true.
This causes few arguments to change places.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Everything spice is not supported (and does not make sense) without spice
graphics. For some tests I also added cirrus VGA capability so that the XML
stays simple and libvirt can guess a default video model rather than adding too
much of an irrelevant XML into the individual tests.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This old test was added by me to allow people to keep the spicevmc
channel while changing graphics type from spice to something else.
However we do not do this in other places and also now we have all the
Validate functions so it is better to show the user they will not have
the spicevmc channel available rather than simply not formatting it on
the qemu command line.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Validate the domain configuration to ensure that if there are more than
one vgpu assigned to a domain, only one of them has 'ramfb' enabled.
This was never a supported configuration. QEMU failed confusingly when
attempting to start a domain with this configuration. This change
attempts to provide better information about the error.
https://bugzilla.redhat.com/show_bug.cgi?id=2079760
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
For finding the best matching CPU model for a given set of features
while we don't know the CPU signature (i.e., when computing a baseline
CPU model) we've been using a "shortest list of features" heuristics.
This works well if new CPU models are supersets of older models, but
that's not always the case. As a result it may actually select a new CPU
model as a baseline while removing some features from it to make it
compatible with older models. This is in general worse than using an old
CPU model with a bunch of added features as a guest OS or apps may crash
when using features that were disabled.
On the other hand we don't want to end up with a very old model which
would guarantee no disabled features as it could stop a guest OS or apps
from using some features provided by the CPU because they would not
expect them on such an old CPU.
This patch changes the heuristics to something in between. Enabled and
disabled features are counted separately so that a CPU model requiring
some features to be disabled looks worse than a model with fewer
disabled features even if its complete list of features is longer. The
penalty given for each additional disabled feature gets bigger to make
longer list of disabled features look even worse.
https://bugzilla.redhat.com/show_bug.cgi?id=1851227
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend the 'disk-cdrom-network' to cover this instance. This also
validates that the parameters of -blockdev conform to the QAPI schema.
Also add the xml2xml variant of this test case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reject encryption requests for unsupported image format types.
Add negative test for the rejected cases as well as modify
'disk-network-rbd-encryption' case to validate that with librbd
encryption the format doesn't matter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was supposed to test the behavior when
QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT is present, but these
days that's always the case and pseries-cpu-compat already
provides all the coverage we need.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Also, validate that the requested feature is supported by QEMU.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Added "rss" and "rss_hash_report" configuration that should be
used with qemu virtio RSS. Both options are triswitches. Used as
"driver" options and affects only NIC with model type "virtio".
In other patches - options should turn on virtio-net RSS and hash
properties.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Starting with qemu-3.1 we always have the '-overcommit' argument and use
it instead of '-realtime'. Remove the capability check and fix all
fake-caps tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All qemu versions now support FD passing either directly or via FDset.
Assume that we always have this capability so that we can simplify
chardev handling in many cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will raise the minimum required qemu version to 3.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-iommu needs to be an integrated device, and our address
assignment code will make sure that is the case. If the user has
provided an explicit address, however, we should make sure any
addresses pointing to a different bus are rejected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-iommu is a PCI device and attempts to use a different
address type should be rejected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-iommu doesn't work without ACPI, so we need to make sure
the latter is enabled.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QEMU binary is built from the v7.0.0-rc2 tag.
This causes the argument to -device to be generated in JSON
format, same as what 1a691fe1c8 has done for x86_64.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The QEMU binary is built from the v7.0.0-rc2 tag.
Some of the additional capabilities that show up are a
consequence of more features being enabled in this build than
in the one used to generate the replies initially.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
While commit a5e659f0 removed the restriction against multiple queues
for the vdpa net device, there were some missing pieces. Configuring a
device statically and then starting the domain worked as expected, but
hotplugging a device didn't have the expected multiqueue support
enabled. Add the missing bits.
Consider the following device xml:
<interface type="vdpa">
<mac address="00:11:22:33:44:03" />
<source dev="/dev/vhost-vdpa-0" />
<model type="virtio" />
<driver queues='2' />
</interface>
Without this patch, hotplugging the above XML description resulted in
the following:
{"execute":"netdev_add","arguments":{"type":"vhost-vdpa","vhostdev":"/dev/fdset/0","id":"hostnet1"},"id":"libvirt-392"}
{"execute":"device_add","arguments":{"driver":"virtio-net-pci","netdev":"hostnet1","id":"net1","mac":"00:11:22:33:44:03","bus":"pci.5","addr":"0x0"},"id":"libvirt-393"}
With the patch, hotplugging results in the following:
{"execute":"netdev_add","arguments":{"type":"vhost-vdpa","vhostdev":"/dev/fdset/0","queues":2,"id":"hostnet1"},"id":"libvirt-392"}
{"execute":"device_add","arguments":{"driver":"virtio-net-pci","mq":true,"vectors":6,"netdev":"hostnet1","id":"net1","mac":"00:11:22:33:44:03","bus":"pci.5","addr":"0x0"},"id":"libvirt-393"}
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2024406
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Apply the user-requested changes to the device definition as requested
by the <qemu:deviceOverride> element from the custom qemu XML namespace.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/287
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit 06c960e477.
Turns out, this feature is not needed and QEMU will fix TSC
without any intervention from outside.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>P
QEMU 7.0.0 adds a new property tsc-clear-on-reset to x86 CPU, corresponding
to Libvirt's <tsc on_reboot="clear"/> element. Plumb it in the validation,
command line handling and tests.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Let's generate prealloc-threads property onto the cmd line if
domain configuration requests so.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since its v5.0.0 release QEMU is capable of specifying number of
threads used to allocate memory. It defaults to 1, which may be
too low for humongous guests with gigantic pages.
In general, on QEMU cmd line level it is possible to use
different number of threads per each memory-backend-* object, in
practical terms it's not useful. Therefore, use <memoryBacking/>
to set guest wide value and let all memory devices 'inherit' it,
silently. IOW, don't introduce per device knob because that would
only complicate things for a little or no benefit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In cases when the hostname of the NBD server doesn't match the hostname
in the TLS certificate the new attribute 'tlsHostname' can be used to
override it.
Add the XML infrastructure and tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By using the auto-generated NVRAM path in test data files, we won't see
bugs where a user specified path gets accidentally overwritten by a
post-parse callback, or VM startup. For example, this caused us to miss
the bug fixed by:
commit 24adb6c7a6
Author: Michal Prívozník <mprivozn@redhat.com>
Date: Wed Feb 23 08:50:44 2022 +0100
qemu: Don't regenerate NVRAM path if parsed from domain XML
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When building the default memory backend (which has id='pc.ram')
and no guest NUMA is configured then
qemuBuildMemCommandLineMemoryDefaultBackend() is called. However,
its return value is ignored which means that on invalid
configuration (e.g. when non-existent hugepage size was
requested) an error is reported into the logs but QEMU is started
anyway. And while QEMU does error out its error message doesn't
give much clue what's going on:
qemu-system-x86_64: Memory backend 'pc.ram' not found
While at it, introduce a test case. While I could chose a nice
looking value (e.g. 4MiB) that's exactly what I wanted to avoid,
because while such value might not be possible on x84_64 it may
be possible on other arches (e.g. ppc is notoriously known for
supporting wide range of HP sizes). Let's stick with obviously
wrong value of 5MiB.
Reported-by: Charles Polisher <chas@chasmo.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This demonstrates that
<os>
<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
<nvram template="/usr/share/OVMF/OVMF_VARS.fd"/>
</os>
gets expanded to give a per-VM NVRAM path.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The following is expected to raise an error:
<os>
<loader readonly='yes' type='pflash'/>
</os>
because no path to the pflash loader is given and there is
no default built-in.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Upcoming patches will remove support for qemu-2.12. Since tests of
'sev' use hacked data we need to use our capability dump of qemu-6.0 as
it has the required fields.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally when I started working on '-blockdev' support I added version
locked variants of all the relevant disk tests locked to qemu-2.12, but
blockdev was finally enabled with qemu-4.2.
This patch bumps the rest of the test cases with no functional changes
related to disks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'device_id' property was added in qemu-4.0. Since upcoming patch
will be modernizing all disk test cases we specifically want to preserve
the instance of 'device_id' not being used with qemu-3.1 and earlier.
Change the 'disk-cache' and 'disk-shared' cases to have a qemu-3.1 and a
qemu-4.1 version for testing pre-'device_id' and pre-blockdev scenarios.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with qemu-3.0 release we use the 'werror' and 'rerror'
properties with the frontend (device) rather than the storage backend
(with a minor caveat of s390, where we use it earlier as it doesn't
support USB disks, and other disk types supported it earlier).
Add specific test cases after the change, but before '-blockdev' was
enabled.
This is done separately from the changes in the next commit which simply
moves all other disk tests to the last pre-blockdev qemu as we have a
semantic change happening after 2.12.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rewrite the parts which already pass FDs via fdset or directly to use
the new infrastructure.
Apart from simpler code this also adds the appropriate names to the fds
in the fdsets which will allow us to properly remove the fdsets won
hot-unplug of chardevs, which we didn't do for now and resulted in
leaking the FDs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prefix the file descriptor name with the alias of the network device so
that it's similar to other upcoming use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Code paths which don't wish to use FD passing are supposed to not call
the function which sets up the chardev for FD passing.
This is ensured by calling it only in the host prepare step.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
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>
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>
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>
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>
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 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>
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 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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
On QEMU command line it's represented by the dirty-ring-size
attribute of KVM accelerator.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Dirty ring feature was introduced in qemu-6.1.0, this patch
add the corresponding feature named 'dirty-ring', which enable
dirty ring feature when starting VM.
To enable the feature, the following XML needs to be added to
the guest's domain description:
<features>
<kvm>
<dirty-ring state='on' size='xxx'>
</kvm>
</features>
If property "state=on", property "size" must be specified, which
should be power of 2 and range in [1024, 65526].
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Generating command line is pretty easy - just put tb-size=XXX
onto -accel tcg part. Note, that QEMU expects the size in MiB.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/229
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
It may come handy to be able to tweak TCG options, in this
specific case the size of translation block cache size (tb-size).
Since we can expect more knobs to tweak let's put them under
common element, like this:
<domain>
<features>
<tcg>
<tb-cache unit='MiB'>128</tb-cache>
</tcg>
</features>
</domain>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since the backend of the TPM is a chardev we can use the common helper
to instantiate it.
This commit also ensures proper ordering so that the backend chardev is
formatted before it's being referenced.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the API for qemuBuildChrChardevCommand is sane enough, we can
use it to centralize formatting of '-chardev' generally.
The 'virDomainVideoDef' doesn't use 'virDomainChrSourceDef' internally so
we create it for this occasion manually.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was impossible to use _LATEST when commit d7c814f7f7 was modernizing
the cases as improper separation in the code caused that files were
created in the host during the testsuite run.
Now that the host manipulation when instantiating chardevs is separated
we can add the missing version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the test cases won't cause host modification we can add the
contemporary versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In other places we use strspn to validate a character subset. Convert
the in-place loop and simplify the error message.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new STRLIM macro and unify it with the empty string check.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We currently use -machine accel=XXX which is just a syntax sugar
for -accel XXX. The former doesn't allow specifying arguments for
accelerator, because all arguments passed to -machine are
treated as arguments of machine itself.
The -accel argument was introduced in QEMU commit
v2.9.0-rc0~70^2~19 and since our minimum required version is
newer (2.11.0) we can safely assume its existence and use it
without any capability.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/233
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When guest has NUMA nodes and QEMU is new enough to report
default RAM ID then ideally we would use -numa memdev= combined
with memory-backend-* combo becasue -mem-path/-mem-prealloc/-numa
mem are deprecated. Well, there is one problem - the .memdev=
attribute is machine type dependent (just look at arguments of
virQEMUCapsGetMachineNumaMemSupported()) and to ensure backwards
compatibility we prefer -numa mem= over -numa memdev=.
But there was one corner case when -mem-prealloc was requested
but not generated on the cmd line. It all starts with
qemuBuildMemCommandLine() which generates just '-m XXX' and
because it sees defaultRAMid and guest NUMA nodes greater than
zero it does nothing more.
Then, qemuBuildNumaCommandLine() sees that -numa mem= is still
supported for given machine type and nothing else set
@needBackend thus qemuBuildMemPathStr() is called which output
-mem-prealloc only in a few cases assuming it was outputted
earlier.
Reported-by: Jing Qi <jinqi@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This test shows a bug we have: even though the XML says:
<allocation mode='immediate'/>
there is no -mem-prealloc nor .prealloc=yes anywhere on the cmd
line. This will be fixed in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a test case where 'ramfb' is explicitly disabled for a mediated
device to prevent regressing again.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 65b0b746b5 changed spice tests to use latest caps. Before this
change, "FLAG_REAL_CAPS" wasn't being set in testQemuInfoInitArgs(). The
absence of this flag triggered the code path inside
testCompareXMLToArgv() that executed testUpdateQEMUCaps(). This function
will update the host CPU via virQEMUCapsUpdateHostCPUModel() into
virQEMUCapsInitHostCPUModel(). In this function,
virQEMUCapsInitCPUModel() would end up updating the hostCPU inside the
qemuCaps (via virQEMUCapsProbeHostCPU()). Before the forementioned
commit, the host CPU was being defaulted to x86_64, vendor Intel, for
the 'graphics-spice-timeout' test that is using the 'pc' machine type
and 'accel=kvm'.
Today, "FLAG_REAL_CAPS" is being set because we're using the latest caps
from x86_64. This means that the whole code path mentioned above is
skipped. qemuCaps are now being loaded via virQEMUCapsLoadCache()
directly. Without the handling being done by testUpdateQEMUCaps(), the
host CPU is being retrieved later on, down below
qemuProcessCreatePretendCmdPrepare() into qemuProcessUpdateGuestCPU().
The latter will attempt to update the domain cpu and executing a
virCPUCompare with the hostCPU and def->cpu.
All this logic ended up causing a failure of the
'graphics-spice-timeout' test in ppc64 and s390x hosts. This test is
being run with KVM acceleration, and the KVM driver for ppc64 and s390x
will return a default x86_64 CPU with vendor "AMD", making
virCPUCompare() fail with the following message:
"QEMU XML-2-ARGV graphics-spice-timeout.x86_64-latest ... libvirt: CPU
Driver error : the CPU is incompatible with host CPU: host CPU vendor does
not match required CPU vendor Intel"
Fix this test by setting cpu check='none' and avoid the virCPUCompare()
that causes the problem for ppc64 and s390x hosts.
Note that this is a build fix. A more adequate fix would be to mock the
getHost() interface of the cpuDriverX86 for non-x86 hosts, allowing
'fullCPU' to be retrieved in qemuProcessUpdateGuestCPU(), and a proper
x86 CPU to be retrieved in the scenario described above.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
'-audiodev' as a modern implementation based on QAPI already takes JSON
as the argument. Convert our code to use it directly.
The declaration of the QAPI types can be found in
'qemu.git/qapi/audio.json'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch updates domaincapsdata and qemucapabilitiesdata for ppc64
with qemu commit v6.1.0-1714-gc5b2f55981.
Changes in all 'ppc64-latest.ags' files were needed. The changes are
mundane despite the volume. For all 'ppc64-latest.args' files the
changes are:
- removing '-sandbox' command line;
- 'secret' and 'memory-backend-ram' objects are now using qom-type format;
- '-device' is now using qom-type format.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Commit 88957116c9 switched to use
memory-backend-* for regular VM memory as well. That change indirectly
started using 'host-nodes' for system memory which results in QEMU
calling mbind() to bind the system memory to specific NUMA node if the
VM XML contains the configuration similar to this:
...
<numatune>
<memory mode='strict' nodeset='0'/>
</numatune>
...
Once the VM was started with that configuration it was no longer
possible to change the memory NUMA nodeset.
Fixes: 677c90cc1d
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend the TPM backend XML with a node 'active_pcr_banks' that allows a
user to specify the PCR banks to activate before starting a VM. Valid
choices for PCR banks are sha1, sha256, sha384 and sha512. When the XML
node is provided, the set of active PCR banks is 'enforced' by running
swtpm_setup before every start of the VM. The activation requires that
swtpm_setup v0.7 or later is installed and may not have any effect
otherwise.
<tpm model='tpm-tis'>
<backend type='emulator' version='2.0'>
<active_pcr_banks>
<sha256/>
<sha384/>
</active_pcr_banks>
</backend>
</tpm>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2016599
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For later QEMUs than 2.11 we do FD passing for character devices,
so lock the capabilites to this exact version.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reduce the churn in following patches.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since b2757b697e
(qemu: support kvm-pv-ipi off), libvirt supports xml definition like:
<features>
<kvm>
<pv-ipi state='off'/>
</kvm>
</features>
Add test case for this feature.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
KVM features off test cases should be tested for a KVM domain, so
keep align kvm-features-off test with kvm-features except KVM
features on/off.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Error messages must conform to spec as specified here:
https://www.libvirt.org/coding-style.html#error-message-format
This change makes some error messages conform to the spec above.
Fixes: 8eadf82fb5 ("conf: introduce option to enable/disable pci hotplug on pci-root controller")
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This reverts commit 7300ccc9b3.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This reverts commit bef0f0d8be.
Conflicts:
tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args
* this file had been renamed from its original, then renamed back,
which understandably confused git. It's being completely removed
here anyway, so the contents don't matter.
tests/qemuxml2argvtest.c
* change in context around removed chunk
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This reverts commit 2d20f0bb05.
Conflicts:
tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.args
tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args
the test output of these files was regenerated because the tests
were changed upstream to use JSON on the commandline at a later
commit than the commit being reverted here (where they were changed
to use latest caps, but the patches to use JSON on the commandline
hadn't been committed yet).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This reverts commit 6414603105.
Conflicts:
tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.x86_64-latest.args
tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.x86_64-latest.args
tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.x86_64-latest.args
These files are unrelated to the functionality we need to remove, so
they weren't removed, and the associated test cases weren't removed
from qemuxml2argvtest.c
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This reverts commit da896d440c.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This commit extends libvirt XML configuration to support luks2 encryption format.
This means that <encryption format="luks2" engine="librbd"> becomes valid.
Currently librbd is the only engine that supports this new format.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
rbd encryption is new in qemu 6.1.0.
This commit adds a new encryption engine property which
allows the user to use this new encryption engine.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This commit extends libvirt XML configuration to support a custom encryption engine.
This means that <encryption format="luks" engine="qemu"> becomes valid.
The only engine for now is qemu. However, a new engine (librbd) will be added in an upcoming commit.
If no engine is specified, qemu will be used (assuming qemu driver is used).
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These were generated using a QEMU binary built from commit
v6.1.0-1552-g362534a643
Notably, this causes the arguments of -device to be generated
in JSON format.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some guest features that map to the -cpu arg are still added using
implicit syntax "feature" which is a deprecated shorthand for
"feature=on".
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The -cpu arg gained support for feature=on|off syntax for the x86
emulator in 2.4.0
commit 38e5c119c2925812bd441450ab9e5e00fc79e662
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Mon Mar 23 17:29:32 2015 -0300
target-i386: Register QOM properties for feature flags
Most other targets gained this syntax even earlier in 1.4.1
commit 1590bbcb02921dfe8e3cf66e3a3aafd31193babf
Author: Andreas Färber <afaerber@suse.de>
Date: Mon Mar 3 23:33:51 2014 +0100
cpu: Implement CPUClass::parse_features() for the rest of CPUs
CPUs who do not provide their own implementation of feature parsing
will treat each option as a QOM property and set it to the supplied
value.
There appears no reason to keep supporting "+|-feature" syntax,
given the current minimum QEMU version.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU switched from using underscores in x86 CPU features to hyphens
in the 2.8.0 series with two commits
commit fc7dfd205f3287893c436d932a167bffa30579c8 (HEAD, refs/bisect/bad)
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:40 2016 -0300
target-i386: Remove underscores from feat_names arrays
commit 54b8dc7c19cd781e96f1e9b001ca6001d804eb19
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:38 2016 -0300
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU switched from using underscores in x86 CPU features to hyphens
in the 2.8.0 series with two commits
commit fc7dfd205f3287893c436d932a167bffa30579c8 (HEAD, refs/bisect/bad)
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:40 2016 -0300
target-i386: Remove underscores from feat_names arrays
commit 54b8dc7c19cd781e96f1e9b001ca6001d804eb19
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:38 2016 -0300
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Starting with QEMU-6.2 started accepting a JSON object as argument for
'-device' which will also become the only syntax considered stable by
qemu in the future.
Since libvirt was recently converted to generate the properties via JSON
to begin wit we can start using it on the commandline as well, by simply
enabling the QEMU_CAPS_DEVICE_JSON capability, which we do by probing
for the 'json-cli' feature flag of 'device_add'.
Normally a change which changes a commandline output should be happening
only after the impacted real-caps test files are forked in the version
preceding the change, but in this case it's not necessary as the logic
for generating the device properties stays identical and we just change
the output format (avoid conversion). Additionally we still have a lot
of tests validating the conversion to the old commandline options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver ats=''/> when
QEMU_CAPS_VIRTIO_PCI_ATS capability is not present. Well, such
scenario can't happen really because the capability will always
be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver iommu=''/> when
QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM capability is not present.
Well, such scenario can't happen really because the capability
will always be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are a few files containing expected output for test cases
that no longer exist. Remove them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We control only the 'tpmdev' property of TPM devices which is a string.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We control the following properties of the devices in question:
'virtio-gpu'
virgl=<bool> - on/off (default: true)
'qxl'
ram_size=<uint32> - (default: 67108864)
vram_size=<uint64> - (default: 67108864)
vram64_size_mb=<uint32> - (default: 4294967295)
vgamem_mb=<uint32> - (default: 16)
max_outputs=<uint16> - (default: 0)
'vhost-user-gpu'
max_outputs=<uint32> - (default: 1)
chardev=<string>
'VGA'
vgamem_mb=<uint32> - (default: 16)
'bochs-display'
vgamem=<size> - (default: 16777216)
common for all devices:
xres=<uint32> - (default: 0)
yres=<uint32> - (default: 0)
The only noticable change is using memory size in bytes for
'bochs-display' instead of kibibytes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Build commandlines for character devices via JSON.
For devices using 'VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL' address
type 'qemuBuildDeviceAddressProps' will now generate the address. The
only special property is 'nr'. QEMU declares it as:
nr=<uint32> - (default: 4294967295)
The test fallout is caused by formatting addresses as decimal numbers
instead of hex as described in the commit which added
'qemuBuildDeviceAddressProps'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the validation code into a separate function. For now the
validation is still kept in the commandline format step as simply just
moving it to the validator causes failures in the test suite, which will
need to be investigated deeper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Internally format the PCI controller properties into JSON, but convert
it back to a string so that we for now change just the SCSI controller.
The change in tests is expected as the 'port' field for various PCI
controllers is expected to be a number and thus can't be represented as
a hexadecimal value in JSON.
QEMU expects the following types:
'pci-bridge'
chassis_nr=<uint8> - (default: 0)
'pxb-pcie':
bus_nr=<uint8> - (default: 0)
'pcie-root-port'
port=<uint8> - (default: 0)
chassis=<uint8> - (default: 0)
hotplug=<bool> - (default: true)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Internally format the SCSI controller properties into JSON, but convert
it back to a string so that we for now change just the SCSI controller.
The change in tests is expected as the 'reg' field for a spapr-vio
address is expected to be a number:
$ qemu-system-ppc64 -device spapr-vscsi,help
spapr-vscsi options:
reg=<uint32> - (default: 4294967295)
The hand-rolled generator used hex representation but that will not be
possible on the monitor via JSON.
The properties of 'virtio-scsi' have following types according to QEMU:
iothread=<link<iothread>>
num_queues=<uint32> - (default: 4294967295)
cmd_per_lun=<uint32> - (default: 128)
max_sectors=<uint32> - (default: 65535)
ioeventfd=<bool> - on/off (default: true)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the bootindex before the address so that the code is simpler.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The types for the special fields of the 'virtio-blk-pci' according to
QEMU are:
iothread=<link<iothread>>
ioeventfd=<bool> - on/off (default: true)
event_idx=<bool> - on/off (default: true)
scsi=<bool> - on/off (default: false)
num-queues=<uint16> - (default: 65535)
queue-size=<uint16> - (default: 256)
For all disks we also use the following properties (based on 'scsi-hd'):
device_id=<str>
share-rw=<bool> - (default: false)
drive=<str> - Node name or ID of a block device to use as a backend
chardev=<str> - ID of a chardev to use as a backend <- vhost-user-blk-pci
bootindex=<int32>
logical_block_size=<size> - A power of two between 512 B and 2 MiB (default: 0)
physical_block_size=<size> - A power of two between 512 B and 2 MiB (default: 0)
wwn=<uint64> - (default: 0)
rotation_rate=<uint16> - (default: 0)
vendor=<str>
product=<str>
removable=<bool> - on/off (default: false)
write-cache=<OnOffAuto> - on/off/auto (default: "auto")
cyls=<uint32> - (default: 0)
heads=<uint32> - (default: 0)
secs=<uint32> - (default: 0)
bios-chs-trans=<BiosAtaTranslation> - Logical CHS translation algorithm, auto/none/lba/large/rechs (default: "auto") <- ide-hd
serial=<str>
werror=<BlockdevOnError> - Error handling policy, report/ignore/enospc/stop/auto (default: "auto")
rerror=<BlockdevOnError> - Error handling policy, report/ignore/enospc/stop/auto (default: "auto")
The 'wwn' field is changed from a hex string to a number since qemu
actually treats it as a number.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the 'deflate-on-oom' and 'free-page-reporting' before the address
to simplify the genrator code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Merge the code from qemuBuildVirtioOptionsStr so that we don't have to
call two separate functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The same test in regards to the 'panic' device is the 'panic-double'
case, thus panic-isa can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have input files for those, provide also xml2argv testing since we
have them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can use real example configs to prove the support without the
need for using fake capabilities. Fix the recently added test cases.
The negative case for 'pc-i440fx-acpi-hotplug-bridge-disable' is removed
completely as there is no real qemu libvirt supports which wouldn't
have the capability.
The input file for the negative test on aarch64 is modified so that it's
actually a reasonably valid VM config.
Fixes: bef0f0d8be
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can use two real example configs to prove the support without the
need for using fake capabilities. Fix the recently added test cases.
Fixes: 133d7983d6
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change adds backend qemu command line support for new libvirt
global feature 'acpi-bridge-hotplug'. This option can be used as
following:
<feature>
<pci>
<acpi-bridge-hotplug state='off|on'/>
</pci>
</feature>
The '<pci>' sub-element under '<feature>' is also newly introduced.
'acpi-bridge-hotplug' turns on the following command line option to
qemu for x86 guests:
(pc): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off|on>
(q35): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off|on>
This change also adds the required qemuxml2argv unit tests in order to
test correct qemu arguments. Unit tests have also been added to test
qemu capability validation checks as well as checks for using this
option with the right architecture.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces a new libvirt sub-element <pci> under
<features> that can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
<features>
<pci>
<acpi-bridge-hotplug state='on|off'/>
</pci>
</features>
The above option is only available for the QEMU driver, for x86 guests
only. It is a global option, affecting all PCI bridge controllers on
the guest.
The 'acpi-bridge-hotplug' option enables or disables ACPI hotplug
support for cold-plugged pci bridges. Examples of bridges include the
PCI-PCI bridge (pci-bridge controller) for pc (i440fx) machinetypes,
or PCIe-PCI bridges and pcie-root-port controllers for q35
machinetypes.
For pc machinetypes in x86, this option has been available in QEMU
since version 2.1. Please see the following changes in qemu repo:
9e047b982452c6 ("piix4: add acpi pci hotplug support")
133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI
bridge hotplug is disabled")
For q35 machinetypes, this was introduced in QEMU 6.1 with the
following changes in qemu repo:
(a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
(b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on
Q35")
The reasons for enabling ACPI based hotplug for PCIe (q35) based
machines (as opposed to native hotplug) are outlined in (b). There are
use cases where users would still want to use native
hotplug. Therefore, this config option enables users to choose either
ACPI based hotplug or native hotplug for bridges (for example for pcie
root port controller in q35 machines).
Qemu capability validation checks have also been added along with
related unit tests to exercise the new conf option.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
The mocked path in the test suite is not in sync with what libvirtd
generates.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The commit adding the vhost-user-fs device forgot to format
the device's alias on the command line.
Thankfully it was not needed yet because virtiofs migration
is not yet supported, but it will be needed in the future
to allow hot(un)plug.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This change adds qemu backend command line support for enabling or disabling
hotplug on the pci-root controller using the 'target' sub-element of the
pci-root controller as shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='off/on'/>' is only valid for pc (i440fx-based x86)
machinetypes and turns on the following command line option that is passed
to qemu for x86 guests:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
Before introduction of this attribute, hotplug was always enabled for
pci-root of an i440fx-based machinetype, and since its introduction
the default setting has always been "on" for those machinetypes.
This change also adds the required qemuxml2argv unit tests in order to test
correct qemu arguments. Unit tests have also been added to test qemu capability
validation checks.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces libvirt xml support to enable/disable hotplug on the
pci-root controller. It adds a 'target' subelement for the pci-root controller
with a 'hotplug' property. This property can be used to enable or disable
hotplug for the pci-root controller. For example, in order to disable hotplug
on the pci-root controller, one has to use set '<target hotplug='off'>' as
shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='on'>' option would enable hotplug for pci-root controller.
This is also the default value. This option is only available for pc machine
types and is applicable for qemu/kvm accelerator only.This feature was
introduced from qemu version 5.2 with the following change in qemu repository:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some reasons why users might to disable hotplug
on PCI root buses.
Related unit tests to exercise the new conf option has also been added.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Nothing special is happening here. All important changes were
done when for 'virtio-pmem' (adjusting the code to put virtio
memory on PCI bus, generating alias using
qemuDomainDeviceAliasIndex(). The only bit that might look
suspicious is no prealloc for virtio-mem. But if you think about
it, the whole purpose of this device is to change amount of
memory exposed to guest on the fly. There is no point in locking
the whole backend in memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
Therefore, the device has two important attributes:
1) block-size, which defines the size of a block
2) requested-size, which defines how much memory (in bytes)
is the device requested to expose to the guest.
The 'block-size' is configured on command line and immutable
throughout device's lifetime. The 'requested-size' can be set on
the command line too, but also is adjustable via monitor. In
fact, that is how management software places its requests to
change the memory allocation. If it wants to give more memory to
the guest it changes 'requested-size' to a bigger value, and if it
wants to shrink guest memory it changes the 'requested-size' to a
smaller value. Note, value of zero means that guest should
release all memory offered by the device. Of course, guest has to
cooperate. Therefore, there is a third attribute 'size' which is
read only and reflects how much memory the guest still has. This
can be different to 'requested-size', obviously. Because of name
clash, I've named it 'current' and it is dealt with in future
commits (it is a runtime information anyway).
In the backend, memory for virtio-mem is backed by usual objects:
memory-backend-{ram,file,memfd} and their size puts the cap on
the amount of memory that a virtio-mem device can offer to a
guest. But we are already able to express this info using <size/>
under <target/>.
Therefore, we need only two more elements to cover 'block-size'
and 'requested-size' attributes. This is the XML I've came up
with:
<memory model='virtio-mem'>
<source>
<nodemask>1-3</nodemask>
<pagesize unit='KiB'>2048</pagesize>
</source>
<target>
<size unit='KiB'>2097152</size>
<node>0</node>
<block unit='KiB'>2048</block>
<requested unit='KiB'>1048576</requested>
</target>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</memory>
I hope by now it is obvious that:
1) 'requested-size' must be an integer multiple of
'block-size', and
2) virtio-mem-pci device goes onto PCI bus and thus needs PCI
address.
Then there is a limitation that the minimal 'block-size' is
transparent huge page size (I'll leave this without explanation).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As with previous test replace the fake caps versions with a combination
of DO_TEST_CAPS_VER(..., "2.11.0") and DO_TEST_CAPS_LATEST().
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the code is refactored add the DO_TEST_CAPS_LATEST versions as
promised in the commit adding the pinned versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions now use the new commandline parser
functions, thus we can remove the old-style commandline generator.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the 3 unix socket tests with real caps versions to demonstrate
that supported qemus no longer use the old syntax.
DO_TEST_CAPS_LATEST versions will be added later.
This also removes duplicate invocation of 'graphics-vnc-socket'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The switch to QemuOpts parser which brought the long-form options
happened in qemu commit 4db14629c3 ("vnc: switch to QemuOpts, allow
multiple servers") released in v2.3.0.
We can always assume this capability and remove the old-style
generators.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the fake caps invocation with invocation binding it to the
oldest supported qemu version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The filesystem commandline doesn't differ in the '-latest' cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real caps instead of fake caps for the legacy cases. This will also
show us when we can remove the old-style code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modern QEMUs don't support the machine type at all. Remove it from our
fake caps generator too and adjust test cases which depend on it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
An update to the machine type was necessary as 's390-ccw' is no longer
supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real caps. The flooppy device still is forbidden for ppc64.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For backend related tests we need to cover the pre-blockdev and
post-blockdev era, so the fake-capability test is converted to a
combination of DO_TEST_CAPS_VER(..., "4.1.0") and DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case fails in pre-blockdev scenarios as it would pass RBD
parameters behind our back but succeeds after as we pass it in JSON form
which doesn't have that defect.
Cover both cases instead of the fake-caps version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the iSCSI disk path in one of the disks of the 'disk-cache' test as
it's the only specialty of 'disk-iscsi' case and remove the now
pointless files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the contents of 'disk-network-iscsi-modern' into 'disk-network-iscsi'
to reuse the name and also invocation with real capablities and remove
the leftovers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Cases for covering disk frontend properties can be converted to
DO_TEST_CAPS_LATEST without any need for intermediate capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert all the disk-related negative cases to use 'latest'
capabilities. The checks are mostly related to validation so using
real capabilities doesn't influence the outcome.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In effor to convert all test cases to real capability testing, this
test doesn't make sense any more as even the oldest QEMU supported
supports USB storage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we no longer support qemus which would miss the necessary
capability, thus the test can't be converted to DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Many disk-related test case have both a fake capability version and one
tied to qemu-2.12. Remove all of those fake caps tests as we have
coverage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU supports the 'password-secret' parameter to pass a QCryptoSecret
since 2.9. Remove the alternate plaintext logic.
Unfortunately this had a ripple effect of removing qemuCaps from a lot
of functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The secret object is supported since qemu-2.6 and can't be compiled out.
Assume the presence to simplify the code.
This enables the use of the secret key for most tests not using real
caps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature is now always present. Remove the negative test case as the
upcomming commit will remove the checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions now support this feature so this test is
pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Added by c8a6ae8bb9 in qemu-v1.5.0 and can't be compiled out. Assume
that it's present and fix all fake-caps tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The option "queue-size" in virtio-blk was added in qemu-2.12.0, and
default value increased from qemu-5.0.0.
However, increasing this value may lead to drop of random access
performance.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently disk-virtio-queues test is now using specifying a fake
capability.
By this commit this test will make use of DO_TEST_CAPS_LATEST.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These are no longer referenced by any existing test as of:
os-firmware-invalid-type -> a9b1375d7d
tseg-explicit-size -> 604990a175
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
SeaBIOS >= 1.11 has built-in support for outputting to the serial
console when QEMU sets -M graphics=off. Our minimum QEMU version
is 2.11.0, which bundled SeaBIOS 1.11. Thus we have no need to
use '-device sga' anymore.
This change results in a slight layout difference for option ROMs
in memory, however, it does not affect the migration data stream
format on the wire and once migration is complete the target QEMU
memory layout for ROMs matches the source QEMU once again.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Cover the case of missing disk target to cover the case fixed by
previous commit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The validation infrastructure doesn't modify the definition and
additionally it makes sense to run the global code first as it's
validating certain corner cases.
The changed error messages from qemuxml2argvtest show that this is
indeed the proper ordering as all changed messages are actually better
describing the error.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The '-no-shutdown' flag prevents qemu from terminating if a shutdown was
requested. Libvirt will handle the termination of the qemu process
anyways and using this consistently will allow greater flexibility for
the virDomainSetLifecycleAction API as well as will allow using
the 'system-reset' QMP command during startup to reinitiate devices
exported to the firmware.
This efectively partially reverts 0e034efaf9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will modify how '-no-reboot' is handled when qemu
supports the 'set-action' QMP command. Add a test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This one will be slightly unstable given that CPU features are being
modified frequently in qemu especially when used with a modern cpu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The host model expansion depends on the capability data, so in this case
it makes sense to have specific invocations of the test for all qemu
versions we have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to q35 in anticipation of using DO_TEST_CAPS* in further patches.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the larger number in the original test to avoid having two files.
Additionally this avoids use of 'host-model' with DO_TEST_CAPS_LATEST in
cases when it isn't necessary for the purpose of the test as the CPU
model tends to change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case doesn't really test anything about the specific CPU. Using
a host-model cpu with DO_TEST_CAPS_LATEST results in commandline changes
every time qemu updates the cpu definiton.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions have this option so there's no need for us
to base it on the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All QEMU versions we support have these and it's very unlikely that they
will be removed. Remove the capability checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All modern qemus support sandboxing so this is covered by other tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature is supported by all supported qemu versions thus covered
thoroughly by other test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test is now pointless since we always assume that this option is
present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming commit will always add the property so the negative tests would
stop working.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with QEMU 6.0, this controller is enabled by default
on aarch64.
https://bugzilla.redhat.com/show_bug.cgi?id=1967187
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We need to pass the 'trim' requests through the copy-on-read filter so
if a user configures a discard policy on the disk the requests get
through to the appropriate format layer in the blockdev tree.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1986509
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
