Assume the two features modern qemus have to bring the test data closer
to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assume the support for the 'pcie-root-port' all modern qemus have to
bring the test data closer to the 'latest' real-caps versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To minimize further churn when coverting to real capabilities, assume
that all fake-caps machines support the piix3 USB controller.
Since we already have solid testing of USB controllers, this will have
effect only in cases when it's not relevant to the test itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename the 'usb-controller-explicit-(unavailable-)q35' test case to
'usb-controller-nec-xhci'. Since this also covers what
'usb-controller-xhci' was testing the latter is removed.
Other 'usb-xhci' test cases which were using the NEC controller are also
renamed to contain the name.
In case of 'usb-controller-qemu-xhci' the negative test case is deleted
as we don't need two cases for missing explicitly specified controller
and the positive case is modernized to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Improve testing of an explicitly requested USB controller without a
model being provided.
For this purpose the 'usb-controller' case is renamed to
'usb-controller-default-i440fx'; 'usb-controller-default-q35' is moved
up to form a group. In both cases tests are covnerted to use
DO_TEST_CAPS_LATEST.
A new 'usb-controller-default-isapc' negative test case is added for
symmetry.
The negative test case 'usb-controller-default-unavailable-q35' is
converted to use latest caps, but stripping the default controller
instead of using fake caps. Additionally for symmetry
'usb-controller-default-unavailable-i440fx' is added although that
doesn't cause failure, but rather a graceful downgrade to use '-usb'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are per-machine type variations on which usb controller will be
picked on an x86_64 machine. Add test cases where a USB controller is
completely missing to cover all 3 cases ('isapc', 'pc', 'q35') when an
USB controller is not explicitly requested by the user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move all controller related tests together and consolidate naming of the
test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In order to minimize further churn, make all fake-caps test assume that
the seccomp sandbox is supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Enable a few defaults that will decrease churn when converting tests to
real capabilities.
Since the fake machines are added only for x86_64 at this point we can
assume that ACPI is present via -machine.
In case of the default ram id assume the same. Additionally the logic
was broken as fake capabilities don't have a version so the default RAM
was never actually populated into fake caps tests.
For CPU we add 'qemu64' as that is the default picked by qemu.
We also assume that qemu requires an explicit backend for -numa, which
is the case for modern machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'numatune-memory' case is completely dropped as it's sufficiently
covered by 'numatune-memnode'.
The positive fake-caps version of 'numatune-memnode' is dropped as it's
covered by the two existing real caps invocations.
'numatune-memory-invalid-nodeset', 'numatune-memnode-invalid-mode',
'numatune-memnode-nocpu', 'numatune-memnodes-problematic' parsing error
negative cases are converted to use latest capabilities.
'numatune-static-nodeset-exceed-hostnode' commandline generation failure
negative case is converted to use latest capabilities.
'numatune-memnode-no-memory', 'numatune-distances',
'numatune-auto-nodeset-invalid', 'numatune-auto-prefer' positive cases
are converted to use latest capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use proper version for negative case of 'hugepages-memaccess3'
QEMU allowed to configure a memory backend for default ram since
qemu-5.2. Fix the test to use real capability data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To minimize upcoming churn in test data when they will be converted to
latest capabilities enable JSON syntax for -device, -object, and -netdev
for all fake caps test files. Doing this should also help git track
renames of the files better as there will be more of consistent context
present.
We can do this safely as internally we generate JSON first and then
back-convert it into the old-style commandline if given qemu doesn't
support it. This means that all generated content will be the same.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to 'cpu-host-model' add a real capability invocation for each
version we support and remove the old fake caps invocation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to 'cpu-host-model' add a real capability invocation for each
version we support and remove the old fake caps invocation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature is supported since qemu-5.1. Use real qemu-5.0 caps for the
test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Drop tests which already are tested with real caps, thus the fake caps
version doesn't bring much value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Change DO_TEST_GIC so that it accepts the version and switch it to use
DO_TEST_CAPS_ARCH_VER_FULL internally which will ensure that the output
filenames conform to the format we use for real capabilities.
This also allows us to convert a few of versioned tests to use this
improved macro.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We've forgot to add test invocations with real caps for qemu versions
starting with 6.2.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'display' option for the 'vfio-pci' device was added in qemu-2.12
and can't be compiled out. Assume support for the flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions have this feature and it can't be compiled
out. The logic is a bit more complex in this instance as the flag is
asserted if:
if (ARCH_IS_X86(qemuCaps->arch) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION)) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_CACHE);
}
Now QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION is available since qemu-2.8 but
only on certain architectures, thus we need to keep the flag itself, but
x86_64 is one of them.
The flag can be also assumed as qemuValidateDomainDefCpu rejects any
cache config on non-x86 arches.
Remove any use of the capability and drop the impossible test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QMP monitor is the only thing we support at this point, thus all other
tests test the same thing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The support for PIIX power management was added in qemu commit
v1.0-3094-g459ae5ea5a and the suport for ICH9 power management was added
in qemu commit v2.2.0-542-g6ac0d8d44c and both can't be compiled out.
This means we can always assume support for these features. Remove the
validation and impossible tests. Move relevant bits from
'q35-pm-disable' to 'q35' test case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit adds building of `discard_granularity` disk option
for qemu commandline.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1849570
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Convert all cases using DO_TEST() to use DO_TEST_CAPS_LATEST() and
remove DO_TEST() to prevent further use.
Most of the changes are related to CPU being present in the output XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert all tests using fake capabilities to use DO_TEST_CAPS_LATEST.
Note that rename detection in git didn't work too well here and the
files may not correspond.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The device was removed in qemu-4.0 and is superseded by 'ivshmem-plain'
and 'ivshmem-doorbell'.
Always report error when the old version is used and drop the irrelevant
tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upgrade the relevant test cases to use latest capabilities. Note that
the 'shmem' (ivshmem) device is no longer supported and will be dropped
later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Historically we've used QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS as witness
that the topology must cover the maximum number ov vcpus. qemu started
to enforce this in qemu-2.5, thus we can now always do the check.
This change also requires aligning the topology in certain test files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Finish the conversion of cases which didn't need any special
capabilities to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the rest of the files using 'qemu-system-i386' to
'qemu-system-x86_64'. The 'cpu*' tests are done separately to emphasise
that there's no change in the output.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert tests which use DO_TEST_NOCAPS in both tests and the
qemuxml2xml variant has a symlink back to the qemuxml2argv input file.
This is done to separate the conversion before a patch converts all
DO_TEST_NOCAPS variants in qemuxml2xmltest to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the emulator and architecture to x86_64, for all non-cpu related
test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At this point we setup the master key with all VMs, so this specific
test case no longer makes sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the previous version of this negative test now passes,
create a new version that still triggers the intended failure.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that, after the recent changes, the test passes, its old
name is no longer accurate.
While at it, enable the xml2xml part for it as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Due to the way the information is stored by the XML parser, we've
had this quirk where specifying any information about the loader
or NVRAM would implicitly set its format to raw. That is,
<nvram>/path/to/guest_VARS.fd</nvram>
would effectively be interpreted as
<nvram format='raw'>/path/to/guest_VARS.fd</nvram>
forcing the use of raw format firmware even when qcow2 format
would normally be preferred based on the ordering of firmware
descriptors. This behavior can be worked around in a number of
ways, but it's fairly unintuitive.
In order to remove this quirk, move the selection of the default
firmware format from the parser down to the individual drivers.
Most drivers only support raw firmware images, so they can
unconditionally set the format early and be done with it; the
QEMU driver, however, supports multiple formats and so in that
case we want this default to be applied as late as possible,
when we have already ruled out the possibility of using qcow2
formatted firmware images.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Keep things consistent by using the same file extension for the
generated NVRAM path as the NVRAM template.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the user included loader.readonly=no in the domain XML, we
should not pick a firmware build that expects to work with
loader.readonly=yes.
https://bugzilla.redhat.com/show_bug.cgi?id=2196178
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now, we only generate it after finding a matching entry
either among firmware descriptors or in the legacy firmware
list.
Even if the domain is configured to use a custom firmware build
that we know nothing about, however, we should still automatically
generate the NVRAM path instead of requiring the user to provide
it manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These are imported from Fedora 38's edk2 package.
The files that are being replaced date back to RHEL 7 and no
longer represent what libvirt is likely to encounter on an
actual production system.
Notably, the paths have all changed, with both x86_64 and
aarch64 builds now living under /usr/share/edk2 and the AAVMF
name being having been phased out.
Additionally, the 4MB qcow2 format builds have been introduced
on x86_64 and given high priority, effectively making qcow2
the default format across architectures.
The impact of these changes on the test suite is, predictably,
quite severe.
For the cases where paths to firmware files were explicitly
provided as part of the input, they have been adjusted so that
the modern paths are used instead of the legacy ones. Other
than that, input files have been left untouched.
The following expected changes can be seen in output files:
* where qcow2 firmware was used on x86_64, Secure Boot
support is now enabled;
* all ABI_UPDATE test cases for x86_64 now use qcow2
formatted firmware;
* test cases where legacy paths were manually provided
no longer get additional information about the firmware
added to the output XML.
Some of the changes described above highlight why, in order
to guarantee a stable guest ABI over time and regardless of
changes to the host's configuration, it was necessary to move
firmware selection from VM startup time to VM creation time.
In a few cases, updating the firmware descriptors changes the
behavior in a way that's undesired and uncovers latent bugs
in libvirt:
* firmware-manual-efi-secboot-legacy-paths ends up with
Secure Boot disabled, despite the input XML specifically
requesting it to be enabled;
* firmware-manual-efi-rw-modern-paths loses the
loader.readonly=no part of the configuration and starts
using an NVRAM file;
* firmware-manual-efi-nvram-template-nonstandard starts
failing altogether with a fairly obscure error message.
We're going to address all these issues with upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Most of these are just additional coverage, but a few demonstrate
bugs in libvirt:
* firmware-manual-efi-nvram-template-nonstandard sees the NVRAM
template path, which was explicitly provided in the XML,
being overridden by the firmware selection machinery;
* firmware-auto-efi-rw* and firmware-manual-efi-rw-legacy-paths
lose the loader.readonly=no setting and thus behave
differently than requested;
* firmware-manual-efi-loader-path-nonstandard fails because an
NVRAM path doesn't get generated.
We're going to address all these issues with upcoming changes.
Note that the firmware-auto-efi-nvram-template-nonstandard
failure is expected: firmware autoselection has been enabled, but
the NVRAM template points to a custom path that's not mentioned
in any of the firmware descriptors and so it can't succeed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The new name better describes the test scenario and will fit
better with the additional tests that we're about to introduce.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since the idea behind introducing the abi-update variant of
a test is showing that libvirt behaves differently based on
whether the configuration is for a newly-defined domain or an
existing one, we don't want the input files to ever go out of
sync.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
That's what we already use in almost all cases.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using the unversioned machine type means that firmware
descriptors can't be used to discover additional information
about the chosen firmware build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Firmware selection is not relevant to these tests, so adopt
the most convenient approach.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have a number of tests that can benefit from this macro
instead of open-coding it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For historical reasons (i.e. unknown reason) we put channel
sockets into a path derived from cfg->libDir which is a path that
survives host reboots (e.g. /var/lib/libvirt/...). This is not
necessary and in fact for session daemon creates a longer prefix:
XDG_CONFIG_HOME -> /home/user/.config
XDG_RUNTIME_DIR -> /run/user/1000
Worse, if host is rebooted suddenly (e.g. due to power loss) then
we leave files behind and nobody will ever remove them.
Therefore, place the channel target dir into state dir.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2173980
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
A <channel/> device is basically an UNIX socket into guest.
Whatever is sent from the host, appears in the guest and vice
versa. But because of that, the length of the path to the socket
is important (underscored by fact that we derive the path from
domain short name). But there are still cases where we might not
fit into UNIX_PATH_MAX limit (usually 108 characters), because
the path is derived also from other variables, e.g.
XDG_CONFIG_HOME for session domains.
There are two components though, that are needless: "/target/"
and "domain-" prefix. Drop them. This is safe to do, because
running domains have their path saved in status XML and even
though paths are dropped on migration, they are not part of guest
ABI and thus we are free to change them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The virtio-gpu 'blob' support was insufficiently validated. Qemu
requires a memfd memory backing in order to use udmabuf and enable blob
support. Example error:
$ virsh start rhel9
error: Failed to start domain 'rhel9'
error: internal error: qemu unexpectedly closed the monitor: 2023-07-18T02:33:57.083178Z qemu-kvm: -device {"driver":"virtio-vga","id":"video0","max_outputs":1,"blob":true,"bus":"pcie.0","addr":"0x1"}: cannot enable blob resources without udmabuf
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically, the way to set PC speaker for a guest was to pass:
-soundhw pcspk
but as of QEMU commit v5.1.0-rc0~28^2~3 this is deprecated and we
should use:
-machine pcspk-audiodev=$id
instead. The old way was then removed in commit v7.1.0-rc0~99^2~3.
Now, ideally we would have a capability selecting whether we talk
to a QEMU that understands the new way or not. But it's not that
simple - the machine attribute is just an alias to the .audiodev=
attribute of 'isa-pcspk' object and both are created in
pc_machine_initfn() function, i.e. not then the PC_MACHINE() class
is initialized, but when it's instantiated. IOW, it's not possible
for us to query whether we're dealing with older or newer QEMU.
But given that the newer version is supported since v5.1.0 and the
minimal version we require is v4.2.0 (i.e. there are two releases
which don't understand the newer cmd line) and how frequently this
feature is (un-)used (the issue was reported after ~1 year since it
stopped working), I believe we can live without any capability and
just use the newer cmd line unconditionally.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/490
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Up until v2.11.0-rc2~19^2~3 QEMU used to require at least one
NUMA node to be configured when memory hotplug was enabled. After
that commit, QEMU automatically adds a NUMA node if none was
specified on the cmd line. Reflect this in domain XML, i.e.
explicitly add a NUMA node into our domain definition if needed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2216236
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Asynchronous teardown can be specified if the QEMU binary supports it by
adding in the domain XML
<features>
...
<async-teardown enabled='yes|no'/>
...
</features>
By default this new feature is disabled.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Let us introduce the xml and reply files for QEMU 8.1.0 on s390x.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Allow //disk/target@removable for scsi disk devices, since QEMU has support
the removable attribute for scsi-hd device from v0.14.0[1].
[1]: 419e691f8e: scsi-disk: Allow overriding SCSI INQUIRY removable bit
Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update to v8.0.0-1739-g5f9dd6a8ce and build on a newer kernel and with
newer libblkio.
Notable changes:
- 'fdset' feature is supported for the vdpa block backend provided by
libblkio
- 'xsaves' feature is optional for EPYC-Rome
- 'cryptodev-backend-lkcf' and 'PIIX3-xen' devices removed
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Qemu 8.1.0 will add discard_no_unref option for qcow2 images.
When this option is enabled (default=false), then it will no longer
unreference clusters when guest does a discard, but it will just free
the blocks (useful for incremental backups for example) and pass the
discard to the lower layer.
This was implemented to avoid fragmentation within the qcow2 image.
Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a config where both DIMM and non-DIMM <memory> devices are used so
that it validates that only DIMMs require memory slots.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Memory slots are required only for DIMM-like devices, but the maximum
memory address space is relevant also for other non-DIMM memory devices
such as virtio-mem. Allow configurations where no slots are added.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Memory slots are required only for DIMM-like devices, while other
devices defined via <memory> such as virtio-mem may use the PCI bus and
thus do not require/consume a memory slot.
Fix the validation code to calculate the required count of memory
devices only for DIMMs and NVDIMMs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Specify the memory size by using '-m size=2048k' instead of just '-m 2'.
The new syntax is used when memory hotplug is enabled. To preserve
memory sizing, if memory hotplug is disabled the size is rounded down to
the nearest mebibyte.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add data as of v8.0.0-1619-g369081c455:
Notable changes:
- 'SapphireRapids' cpu model added
- 'EPYC-Genoa(-v1)' cpu model added
- 'EPYC-Milan-v2' cpu model added
- 'EPYC-Rome-(v3|v4)' cpu models added
- new cpu features:
'fb-clear', 'cmpccxadd', 'vnmi', 'flush-l1d', 'avx-vnni-int8', 'avx-ifma',
'no-nested-data-bp', 'null-sel-clr-base', 'amd-psfd', 'auto-ibrs', 'amx-fp16',
'prefetchiti', 'lfence-always-serializing', 'avx-ne-convert'
- 8.1 machine types added
- QMP schema:
- 'block-latency-histogram-set' gained 'boundaries-zap' property
- 'qcow2' block driver gained 'discard-no-unref' flag
- 'input-send-event' now supports the 'mtt' type and corresponding properties
- 'memory-backend-file' object now has a 'offset' property
- 'query-blockstats' reports 'failed_zone_append_operations', 'avg_zone_append_latency_ns'
'avg_zone_append_queue_depth', 'zone_append_bytes', 'zone_append_latency_histogram',
'zone_append_operations', 'zone_append_merged', 'zone_append_total_time_ns'
- 'single-step' property of 'query-status' is deprecated
- 'vcpu' argument of 'trace-events-(set|get'-state' is deprecated
'cpu-host-model' qemuxml2argv test output changed as EPYC-Rome gained
few new cpu flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We allow (some) domain devices to have a different <seclabel/>
than the top level domain one (this is mostly to allow access to
a resource for multiple domains). Now, we do couple of sanity
checks for such <seclabel/>, e.g. when the <label/> is specified,
but '@relabel' is set to no. But what we are missing is the
opposite: when '@relabel' is set, but no <label/> was provided.
Our schema already denies such combination. Make our parser
behave the same.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160356
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is fairly trivial. Just set .memaddr attribute if a value
was set in the XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2180679
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Both virtio-mem and virtio-pmem devices have '.memaddr' attribute
which controls the address where they are mapped in the guest
memory. Ideally, users do not need to specify this as QEMU does
the right thing and computes addresses automatically on startup.
But soon, we will need to record this address as it is part of
guest ABI. And also, there might be some users that want to
control this value. Now, we are in a bit of a pickle, because
both these device types already have a PCI address, therefore we
can't just use <address/> blindly. But what we can do, is
introduce <address/> under the <target/> element. This is also
more conceptual, as knobs under <target/> control guest visible
config of memory device (and .memaddr surely falls into that
category).
NB, SgxEPCDeviceInfo struct in QMP definition also has .memaddr
attribute, but because of the way we build cmd line there's no
(easy) way to set the attribute. So ignore that for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The QEMU interface is still in a state of flux, and KVM support
has been pulled shortly after having been merged. Let's not
commit to a stable interface in libvirt just yet.
Reverts: 720e8f13ff
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
The QEMU interface is still in a state of flux, and KVM support
has been pulled shortly after having been merged. Let's not
commit to a stable interface in libvirt just yet.
Reverts: b10bc8f7ab
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
We already do check that if there's <memory mode='restrictive'/>
then all <memnode/> have to be of 'restrictive' mode too. But
what we are missing the reverse: if there is <memnode/> with
'restrictive' mode, then the <memory/> has to be of the same mode
too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2208946
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The parser makes the values mandatory and also the qemu code implements
actions for those values. The formatter skips them though. Since
format+parse is used to copy the XML at startup a definition with those
values can't be started.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2203709
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Convert all of the 'audio-default-*' cases to use capabilities from
qemu-4.2 instead of the fake caps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is pretty trivial, just append "mte=on/off" to -machine
arguments.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The Memory Tagging Extensions are hardware acceleration present
in some ARM processors that allow memory error detection [1].
Introduce a domain XML knob that turns them on or off.
1: https://www.arm.com/blogs/blueprint/memory-safety-arm-memory-tagging-extension
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Allow users controlling the multi-channel mode by adding a
'multichannel' property parsed for USB audio devices and wire up the
support in the qemu driver.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/472
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Drop the unnecessary disk definition and use x86_64 emulator.
For 'qemuxml2argvtest' replace the fake-caps invocation by a 4.2.0
version-locked invocation and add a '_CAPS_LATEST' invocation.
For 'qemuxml2xmltest' convert to use '_CAPS_LATEST' only.
There are no sound-device relevant changes in the output files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case is a subset of what the 'sound-device' case tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement the support for the persisted poll parameters and remove
restrictions on saving config when modifying them during runtime.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we allow configuring the 'poll-max-ns', 'poll-grow', and
'poll-shrink' parameters of qemu iothreads only during runtime and they
are not persisted. Add XML machinery to persist them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Treat:
<maxphysaddr mode="emulate"/>
as a request not to take the maximum address size from the host.
This is useful if QEMU changes the default.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
We can launch qemu with it, but it will not work since it's not even
probed by the kernel at the mapped address with different machine types
since they are expected to be connected to ISA and not even its newer
LPC counterpart found on q35. And it does not exist on non-x86
architectures.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
That's already the case in practice, but it's a better
experience for the user if we reject this configuration
outright instead of silently ignoring part of it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a small kludge in the parser to avoid unnecessarily
blocking incoming migration from a range of recent libvirt
releases.
https://bugzilla.redhat.com/show_bug.cgi?id=2184966
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The canonical order for <os> child elements is <firmware>
then <loader>.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions at this point support both 'qemu-xhci' and
'nec-xhci' controllers. To allow using real capabilities restructure the
tests so that we test both controllers explicitly as well as the
selection of the default model.
Also add a xml2xml test invocation of the unified test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fake-caps version was kept as an example that the code behaves the
same with real capabilities. Now it's not needed any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With all supported qemu versions we'll pick PCIe to use for the implicit
address busses (those lacking an explicit controller) and thus the
addresses must reflect that.
Update the test to add the new flags, and fix the addresses.
Additionally add a real-caps version of the test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make the output changes of upcoming modernization more visible.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
