We've recently stopped checking for the presence of various
commands at build time, which means that we no longer need
to have the corresponding packages installed in the build
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_capabilities: Add emulated NVMe disk support to domain capabilities
This is a separate commit for review ease, but who's really going to use
a libvirt with this patch in and the actual functionality missing, that
ain't gonna happen, right?
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_capabilities: Add NVMe controller and disk capabilities
The "nvme" device is the controller and "nvme-ns" are the
namespaces (individual disks) plugged into it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
NVMe disks are essentially a namespace of an NVMe controller, but to
make it easier for the users to just add a disk, the necessary details
like adding the proper controller, setting the serial number for the
controller based on the disk, are done automatically.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We do not guarantee that the disk names will be the same in guest as
they are in the XML, but that should not stop us from trying to be
consistent with the naming. And since we use the same naming as the
linux kernel does, let's stick with it with nvme drives too.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
docs, conf, schemas: Add support for NVMe controller
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Honglei Wang <honglei.wang@smartx.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
nodedev: add nodedev name to mdevctl unsupport msg
Let's add the nodedev name to improve the error message for the user.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
anonymix007 [Wed, 4 Jun 2025 09:05:23 +0000 (12:05 +0300)]
qemu: capabilities: Check if cpuModels is not NULL before trying to dereference it
accel->cpuModels field might be NULL if QEMU does not return CPU models.
The following backtrace is observed in such cases:
0 virQEMUCapsProbeQMPCPUDefinitions (qemuCaps=qemuCaps@entry=0x7f1890003ae0, accel=accel@entry=0x7f1890003c10, mon=mon@entry=0x7f1890005270)
at ../src/qemu/qemu_capabilities.c:3091
1 0x00007f18b42fa7b1 in virQEMUCapsInitQMPMonitor (qemuCaps=qemuCaps@entry=0x7f1890003ae0, mon=0x7f1890005270) at ../src/qemu/qemu_capabilities.c:5746
2 0x00007f18b42fafaf in virQEMUCapsInitQMPSingle (qemuCaps=qemuCaps@entry=0x7f1890003ae0, libDir=libDir@entry=0x7f186c1e70f0 "/var/lib/libvirt/qemu",
runUid=runUid@entry=955, runGid=runGid@entry=955, onlyTCG=onlyTCG@entry=false) at ../src/qemu/qemu_capabilities.c:5832
3 0x00007f18b42fb1a5 in virQEMUCapsInitQMP (qemuCaps=0x7f1890003ae0, libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955)
at ../src/qemu/qemu_capabilities.c:5848
4 virQEMUCapsNewForBinaryInternal (hostArch=VIR_ARCH_X86_64, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha",
libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955,
hostCPUSignature=0x7f186c1e9f20 "AuthenticAMD, AMD Ryzen 9 7950X 16-Core Processor, family: 25, model: 97, stepping: 2", microcodeVersion=174068233,
kernelVersion=0x7f186c194200 "6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000", cpuData=0x7f186c1ea490)
at ../src/qemu/qemu_capabilities.c:5907
5 0x00007f18b42fb4c9 in virQEMUCapsNewData (binary=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", privData=0x7f186c194280)
at ../src/qemu/qemu_capabilities.c:5942
6 0x00007f18bd42d302 in virFileCacheNewData (cache=0x7f186c193730, name=0x7f1868002fc0 "/usr/bin/qemu-system-alpha") at ../src/util/virfilecache.c:206
7 virFileCacheValidate (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", data=data@entry=0x7f18b67c37c0)
at ../src/util/virfilecache.c:269
8 0x00007f18bd42d5b8 in virFileCacheLookup (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha")
at ../src/util/virfilecache.c:301
9 0x00007f18b42fb679 in virQEMUCapsCacheLookup (cache=cache@entry=0x7f186c193730, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha")
at ../src/qemu/qemu_capabilities.c:6036
10 0x00007f18b42fb785 in virQEMUCapsInitGuest (caps=<optimized out>, cache=<optimized out>, hostarch=VIR_ARCH_X86_64, guestarch=VIR_ARCH_ALPHA)
at ../src/qemu/qemu_capabilities.c:1037
11 virQEMUCapsInit (cache=0x7f186c193730) at ../src/qemu/qemu_capabilities.c:1229
12 0x00007f18b431d311 in virQEMUDriverCreateCapabilities (driver=driver@entry=0x7f186c01f410) at ../src/qemu/qemu_conf.c:1553
13 0x00007f18b431d663 in virQEMUDriverGetCapabilities (driver=0x7f186c01f410, refresh=<optimized out>) at ../src/qemu/qemu_conf.c:1623
14 0x00007f18b435e3e4 in qemuConnectGetVersion (conn=<optimized out>, version=0x7f18b67c39b0) at ../src/qemu/qemu_driver.c:1492
15 0x00007f18bd69c5e8 in virConnectGetVersion (conn=0x55bc5f4cda20, hvVer=hvVer@entry=0x7f18b67c39b0) at ../src/libvirt-host.c:201
16 0x000055bc34ef3627 in remoteDispatchConnectGetVersion (server=0x55bc5f4b93f0, msg=0x55bc5f4cdf60, client=0x55bc5f4c66d0, rerr=0x7f18b67c3a80,
ret=0x55bc5f4b8670) at src/remote/remote_daemon_dispatch_stubs.h:1265
17 remoteDispatchConnectGetVersionHelper (server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60, rerr=0x7f18b67c3a80, args=0x0, ret=0x55bc5f4b8670)
at src/remote/remote_daemon_dispatch_stubs.h:1247
18 0x00007f18bd5506da in virNetServerProgramDispatchCall (prog=0x55bc5f4cae90, server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60)
at ../src/rpc/virnetserverprogram.c:423
19 virNetServerProgramDispatch (prog=0x55bc5f4cae90, server=server@entry=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60)
at ../src/rpc/virnetserverprogram.c:299
20 0x00007f18bd556c32 in virNetServerProcessMsg (srv=srv@entry=0x55bc5f4b93f0, client=<optimized out>, prog=<optimized out>, msg=<optimized out>)
at ../src/rpc/virnetserver.c:135
21 0x00007f18bd556f77 in virNetServerHandleJob (jobOpaque=0x55bc5f4d2bb0, opaque=0x55bc5f4b93f0) at ../src/rpc/virnetserver.c:155
22 0x00007f18bd47dd19 in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164
23 0x00007f18bd47d253 in virThreadHelper (data=0x55bc5f4b7810) at ../src/util/virthread.c:256
24 0x00007f18bce117eb in start_thread (arg=<optimized out>) at pthread_create.c:448
25 0x00007f18bce9518c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Michal Privoznik [Mon, 26 May 2025 08:41:00 +0000 (10:41 +0200)]
libxl_capabilities: Make some functions return void
Inside of libxlMakeDomainCapabilities() there are some functions
called and basically all of them never return anything but zero
(indicating success). Yet, they are called in a fashion that
suggests otherwise. Turn those functions into void and drop
checks for their retvals.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, domain capabilities do not include information about the
supported console device types. While most of the drivers support
'pty' console type, it's not the case for bhyve. Without this
information, management software cannot always generate compatible
domain configuration.
To address that, extend domain capabilities like that:
Previously, the RDP graphics definition parsing were implemented by
string parsing, the virDomainGraphicsDefParseXMLRDP function is
refactored to use the appropriate virXMLProp* utility functions.
Overall parsing logic was not changed and results the same output as
before.
Moreover, 'replaceUser' and 'mutliUser' params type was changed from
bool to tristate type, to avoid unnecessary type convertions.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, the fullscreen option were parsed as a tristate but stored
as a bool type, changed the fullscreen option type to tristate bool to
avoid unnecessary type convertions.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, the VNC graphics definition parsing were implemented by
string parsing, the virDomainGraphicsDefParseXMLVNC was refactored
to use the appropriate virXMLProp* utility functions. Overall
parsing logic was not changed and results the same output as before.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Don't accept VIR_DUMP_LIVE flag in qemuDomainCoreDumpWithFormat()
QEMU can't really do live dumps of guest memory. It's because
inside of dump_init() the vm_stop() is called basically
unconditionally (the only condition is whether vCPUs are
running). Hence, there is no way for us to do live dumps and thus
honor VIR_DUMP_LIVE flag. Instead of silently pretending the flag
works, reject it with appropriate error message.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/646 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 2 Jun 2025 14:55:16 +0000 (16:55 +0200)]
qemu: command: Don't attempt to set backend MTU for networks which don't use host backend directly
Attempting to set MTU for network types which don't actually use the
network device on the host results in a failure. The 'mtu' property is
also used e.g. for the 'host_mtu' property of e.g. 'virtio-net-pci'
which is applied even in vhost-user mode.
Use the existing switch which selects devices without a network device
backend on the host side and skip setting the MTU.
Tested by running 'passt' in vhost-user mode manually:
Peter Krempa [Mon, 2 Jun 2025 08:26:38 +0000 (10:26 +0200)]
esx: Avoid corner case where esxUtil_ParseDatastorePath could be called with NULL 'datastorePath'
The generated code which parses the data from XML in
esxVI_LookupDatastoreContentByDatastoreName can fill the 'folderPath'
property with NULL if it were missing from the input XML. While this is
not likely when talking to esx it is a possible outcome. Skipp NULL
results.
All other code paths already ensure that the function is not called with
NULL.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/776 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 2 Jun 2025 08:56:32 +0000 (10:56 +0200)]
docs: Change units to 'kiB' from 'kB'/'kilobytes'/'kb'
Use the short unit for kibibytes instead of the confusing or plainly
wrong units.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/594 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Wed, 28 May 2025 15:36:13 +0000 (17:36 +0200)]
storage_file_probe: Call qcow2GetFeatures from qcow2GetImageSpecific
Parse qcow2 feature flags from qcow2GetImageSpecific. To achieve that
qcow2GetFeatures is refactored to take virStorageSource directly and
fill the data. To avoid the need to pass 'format' the parsing of the
qcow2 version is changed to access the offset directly (same as in
qcow2GetExtensions)
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the two functions to where they will be used. Subsequent patches
will refactor the control flow so that they will no longer be declared
ahead of time. Moving them in a separate patch will make the changes in
the refactor more clear to see.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 28 May 2025 15:26:13 +0000 (17:26 +0200)]
storage_file_probe: Move logic from qcow2GetClusterSize to qcow2GetImageSpecific
Move the cluster size parser into the image specific code for qcow2,
which will later allow us to remove the callback for cluster size which
is not used by any other format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 28 May 2025 15:18:36 +0000 (17:18 +0200)]
storage_file_probe: Refactor qcowXGetBackingStore into specific callbacks for qcow and qcow2
Change qcowXGetBackingStore to use the new function prototype which
fills virStorageSource directly. Convert the copying of the backing file
string from 'g_new0' + 'memcpy' to 'g_strndup' as we treat it as a
string.
Introduce qcowGetImageSpecific (as a wrapper for qcowXGetBackingStore)
and qcow2GetImageSpecific. The latter of the two will be used to collect
all the qcow2-specific code later on, but for now it just parses the
backing store and the format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 28 May 2025 13:59:33 +0000 (15:59 +0200)]
storage_file_probe: Add image specific callback taking the whole virStorageSource
The callbacks getting just some fields are not flexible and in some
cases cause the metadata to be probed multiple times.
Add a callback that will pass the whole virStorageSource struct being
probed so that the code can be written more efficiently.
As a first step we add just the callback. The specific format helpers
will be refactored and subsequently all the other callbacks will be
removed.
To simplify the refactors that will convert all the code to the new
callbacks the new callback is placed first but the calls to cleanup
previous metadata are moved before it. They'll be removed once the
refactors are complete together with the other callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 29 May 2025 08:31:46 +0000 (10:31 +0200)]
virstoragetest: Add qcow2 bitmaps to some images
Add change block tracking bitmaps to some of the qcow2 images, to ensure
that they work with our qcow2 header parser even when we don't parse
them ourselves.
There are 3 bugs in the qcow2 header extension parser:
1) Header extension padding not taken into account
Per qcow2 documentation (qemu.git/docs/interop/qcow2.txt, also now
mirrored in the comment explaining the parser) each header extension
entry is padded to a multiple of 8 bytes.
Our parser didn't take the padding into account and advanced the
current offset only by the 'length', which corresponds to the length
of the data.
This meant that in vast majority of cases only the first extension
would be parsed correctly. For any other one we'd try to fetch the
magic and length from wrong place.
Luckily this wasn't a problem for most of the almost 15 years this bug
existed as we only cared about the backing file format string header
which was always stored first by qemu.
It is now a problem in the very specific case when a qcow2 image has a
'data-file' and also a backing store with format. In such case we'd
parse the backing store format properly as it's the first header and
'data-file' being the second would be skipped.
The buffer bounds checks were correct so we didn't violate any memory
boundaries.
2) Integer underflow in calculation of end of header extension block
If the image doesn't have a backing image, the 'backing_file_offset'
qcow2 header field is 0. We use that value as 'extensions_end' which
is used in the while loop to parse the extension entries.
The check was done as "offset < (extensions_end - 8)", thus it
unreflows when there's no filename.
The design of the loop prevented anything bad from happening though.
3) Off-by-one when determining end of header extension block
The aforementioned end of extension check above also has an off-by-one
error as it allowed another loop if more than 8 bytes were available.
Now the termination entry has data length of 0 bytes so we'd not be
able to properly process that one.
This wasn't a problem either as for now there's just the terminator
having 0 byte length.
This patch improves documentation by quoting the qcow2 interoperability
document and adjusts the loop condition and length handling to comply
with the specs.
Interestingly we also had a test case for this specific scenario but the
expected test output was wrong.
Fixes: a93402d48b2996e5300754d299ef0d3f646aa098
Resolves: https://issues.redhat.com/browse/RHEL-93775 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Sun, 25 May 2025 06:12:48 +0000 (08:12 +0200)]
qemu.conf: Document options for VxHS block network protocol TLS config as ignored
qemu-5.2 dropped support for VxHS. As we now require at least qemu-6.2,
the qemu.conf option for setting up TLS for VxHS are no longer used.
Document them as such.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Sun, 25 May 2025 06:18:21 +0000 (08:18 +0200)]
qemu: block: Drop code for 'vxhs' storage protocol
qemu-5.2 dropped support for the 'vxhs' protocol. We require qemu-5.2
since commit ce48d584cc4 and thus the block code for vxhs is now dead.
Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Tue, 3 Jun 2025 08:33:03 +0000 (10:33 +0200)]
util: Avoid statfs in virFileGetExistingParent
The code was separated from virFileIsSharedFSType which is Linux-only,
but virFileGetExistingParent is also called from
virFileIsSharedFSOverride which is OS independent. Thus we can't use
statfs. Let's use virFileExists (access) instead, we were not interested
in anything but success/failure from statfs anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Jiri Denemark [Wed, 28 May 2025 14:37:32 +0000 (16:37 +0200)]
util: Fix virFileIsSharedFSOverride on nonexistent paths
Commit v11.0.0-162-gf2023e8018 added path canonicalization to
virFileIsSharedFSOverride to make sure we can properly match shared
filesystem override paths which include symlinks. But
virFileCanonicalizePath only works on existing paths, while
virFileIsSharedFSOverride may be called on paths that do not exist yet.
Matching paths against overrides has always worked even for nonexistent
paths. To fix the regression we need to first get the longest existing
sub-path and canonicalize only this part and use the result for
searching in overrides. Clearly any portion of the path we dynamically
create is not going to end up on a different filesystem to what the
parent directory is stored in. So checking just the existing parent is
enough.
https://issues.redhat.com/browse/RHEL-86592
Fixes: f2023e8018fe18550ad6aec66fe72bd1376f8522 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 28 May 2025 14:36:59 +0000 (16:36 +0200)]
util: Introduce virFileGetExistingParent helper
The code from virFileIsSharedFSType which finds the longest existing
path for a given input is separated into a new helper so that it can be
reused elsewhere.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Tue, 27 May 2025 13:42:36 +0000 (15:42 +0200)]
qemu: Fix error when migration with shared TPM storage is unsupported
The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported
driver APIs. It is incorrectly used when swtpm does not support
migration with shared storage resulting in a rather strange error
message:
this function is not supported by the connection driver: the running
swtpm does not support migration with shared storage
The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much
better message:
Operation not supported: the running swtpm does not support
migration with shared storage
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Tue, 27 May 2025 09:48:49 +0000 (11:48 +0200)]
qemu: Fix crash when resuming failed post-copy migration
Since commit 28a06215280 (released in 11.2.0) resuming a failed
post-copy migration calls qemuProcessIncomingDefNew with fd == NULL
rather than -1. The function does not expect to be called with NULL file
descriptor and tries to dereference it causing virtqemud on the
destination host to crash.
Fixes: 28a06215280b99708ed8dc2d183f62ba7b34ccf8 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 21 May 2025 15:01:21 +0000 (17:01 +0200)]
docs: domain: Explain supported options of 'error_policy'
Explain what the individual settings actually result in. The changes
are based on the paraprhase of qemu documentation which in
'qemu-options.hx' states:
``werror=action,rerror=action``
Specify which action to take on write and read errors. Valid
actions are: "ignore" (ignore the error and try to continue),
"stop" (pause QEMU), "report" (report the error to the guest),
"enospc" (pause QEMU only if the host disk is full; report the
error to the guest otherwise). The default setting is
``werror=enospc`` and ``rerror=report``.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/138 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 22 May 2025 18:49:51 +0000 (20:49 +0200)]
qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY
Refuse to use floppy devices if qemu doesn't support them. Reflect that
also in capabilities. Both of the above is achieved by checking for the
QEMU_CAPS_BUS_FLOPPY in qemuDomainMachineSupportsFloppy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce a common capability for support of floppy devices by qemu.
Floppy support can be compiled out ('FDC', 'FDC_ISA', 'FDC_SYSBUS' qemu
Kconfig options) and also isn't supported by all architectures. Add a
capability that will check for 'isa-fdc' and 'sysbus-fdc' devices and
signal that given qemu supports the floppy bus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 23 May 2025 14:38:32 +0000 (16:38 +0200)]
qemu: Move floppy device support validation to validation code
Move the validation from qemuProcessStartValidateDisks to
qemuValidateDomainDeviceDefDiskFrontend and adjust the test case which
now fails a bit earlier, thus no output XML is needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 21 May 2025 16:14:51 +0000 (18:14 +0200)]
libvirt_nss: Allocate buffer in aiforaf() dynamically
While we were trying to decrease stack usage of some functions,
in v9.8.0-rc1~217 we introduced a couple of internal blocks to
the aiforaf() and declared some variables inside those blocks
hoping the compiler will reuse the stack for each block. While in
general this might be a good strategy, specifically in case of
NSS_NAME(gethostbyname2) this is a terrible thing to do.
Problem is, NSS_NAME(gethostbyname2) is given a caller allocated
buffer and an address of a pointer where the resolved address is
stored. And you've probably guessed it already: upon successful
return, the pointer is set to point somewhere inside the buffer.
Now, if the buffer doesn't live long enough, which in our case it
does not (since it was left in the previous block), we should
refrain from dereferencing the resolved pointer.
Just allocate the buffer on the heap.
Fixes: 9e5f2fe4021ada74adbe34ca03be60812c91f334 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Wed, 21 May 2025 16:14:38 +0000 (18:14 +0200)]
libvirt_nss: Allocate buffer in ERROR() dynamically
So far, inside of the ERROR() macro there's pretty large buffer
allocated on the stack (for use by strerror_r()). Problem is,
with our current stack size limit of 2048 bytes we may come
pretty close to the limit or even overshoot it, e.g. in aiforaf()
where the function itself declares another stack allocated buffer
1024 bytes long.
Just allocate the buffer dynamically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 21 May 2025 15:26:01 +0000 (17:26 +0200)]
nss: Declare g_autofree and g_steal_pointer() macros
While we do not want the nss plugin to link with anything but
necessary libs (libc and libjson-c) it can benefit from automatic
memory freeing. Instead of inventing macros with new name for
them, lets stick with g_autofree and g_steal_pointer() which we
are used to from the rest of the code. Borrow and simplify
definitions for these macros then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Thu, 22 May 2025 07:17:16 +0000 (09:17 +0200)]
nss: Add missing includes for gai_strerror()
There are two places where gai_strerror() is called but neither
of them includes all necessary header files as documented in its
manpage. Fortunately, both calls occur in ERROR() macro which by
default does nothing - hence we don't see any compilation errors.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Wed, 21 May 2025 12:52:55 +0000 (14:52 +0200)]
libvirt_nss_macs: Fix type of @len in findMACsFromJSON()
Inside of findMACsFromJSON(), the retval of
json_object_array_length() is stored in a variable that's type of
int. But the function is declared to return size_t:
Narayana Murty N [Tue, 13 May 2025 07:43:26 +0000 (03:43 -0400)]
cpu_ppc64: Add POWER11 host-model support
This patch adds POWER11 CPU host-model support in libvirt's ppc64
CPU driver. With this addition, guests using CPU mode 'host-model'
can specify POWER11 as the CPU model and have libvirt handle it
correctly.
With this change, libvirt can generate correct QEMU command line using
`-machine ... max-cpu-compat=power11` when a POWER11 host-model guest is
defined. This aligns with the QEMU support for POWER11 compatibility mode
starting from version 10.0.0.
Test coverage includes:
- XML validation tests for POWER11 host model
- Negative test for invalid compatibility on POWER10 hosts
- Command line generation tests for POWER11 guests
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Tested-By: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-By: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Narayana Murty N [Tue, 13 May 2025 07:43:25 +0000 (03:43 -0400)]
cpu_map: Add POWER11 CPU model support
Add support for the POWER11 CPU model in libvirt ppc64 CPU map. This
allows libvirt to recognize and handle guests that specify POWER11 as
the target CPU model when running on recent Power systems supporting
this architecture.
The addition includes:
- A new src/cpu_map/ppc64_POWER11.xml definition file describing the
features and flags for POWER11 CPUs.
- Updates to src/cpu_map/index.xml and build system (meson) to include
the new model.
- Test updates to qemucapabilitiesdata and qemuxmlconfdata to reflect
the presence of POWER11 in supported CPU models.
- Adjustments to existing test XMLs to fix CPU model expectations
and avoid mismatches during validation against QEMU output.
With this change, users can specify <model>POWER11</model> in guest CPU
configuration and have libvirt map it correctly to the corresponding
QEMU CPU model and capabilities.
Tested with:
- QEMU 10.0.0 on POWER11 host system
- Validated with updated domain capabilities and qemu capabilities tests
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Tested-By: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-By: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Narayana Murty N [Tue, 13 May 2025 07:43:24 +0000 (03:43 -0400)]
tests: Add capabilities for QEMU 10.0.0 on ppc64
Add the qemu test capabilities xml and reply files for
QEMU v10.0.0 on ppc64. A QEMU v10.0.0 was used for generating
this data.The tests with the 'latest' suffix, which expect
the latest available CPU version from the capabilities XML,
are bumped up to the latest CPU version.
Notable changes:
- new pseries-10 machine type
- old machine types (2.7) dropped
- new CPU models power11 added
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Narayana Murty N [Tue, 13 May 2025 07:43:23 +0000 (03:43 -0400)]
tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests
Commit 140ff3c5141 ("tests: qemuhotplugtest: Fix arch-specific parts of
'ppc64' test XMLs") hardcoded the CPU model as POWER9 in the test result
XMLs. However, this value actually reflects the host CPU model detected
at build or test time, and can vary depending on the machine where the
tests run.
As newer POWER CPU models (e.g., POWER10, POWER11) become common, this
requires continuous updates to the test result files to match the CPU
version detected on the host. This adds unnecessary maintenance effort.
Fix this by updating the test source domain XMLs to specify POWER9 (or
any fixed version) as the CPU model. This ensures the test result files
stay stable and do not require updates every time a newer CPU is used on
the host system.
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Narayana Murty N [Tue, 13 May 2025 07:43:22 +0000 (03:43 -0400)]
tests: Pin pseries-2.7 tests to the version 7.0
Support for the pseries-2.7 machine type in QEMU was officially removed in
version 9.2 with qemu commit 445d3facffe8 ("ppc/spapr: remove deprecated
machine pseries-2.7"). Instead of removing related tests, they are now pinned
to the latest available capabilities version 7.0.0 to ensure continued
functionality where applicable.
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 22 May 2025 12:13:15 +0000 (14:13 +0200)]
virsh: Do not print warnings with "error:" prefix
Both vshWarn and vshError are just wrappers around vshPrintStderr which
properly propagates the message level to the log, but fails to honor it
when printing on stderr.
https://issues.redhat.com/browse/RHEL-79460
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
