Ján Tomko [Wed, 10 Sep 2025 07:48:41 +0000 (09:48 +0200)]
build: bump minimum glib version to 2.68
We removed support for Debian 11 which only had 2.66.8.
Next stop: 2.72 after we drop Ubuntu 22.04
For libvirt, the update to the 2.68 GLib release:
* introduces g_string_replace
* deprecates g_memdup in favor of g_memdup2
* removes the need for some warning workarounds
* deprecates g_time_zone_new in favor of g_time_zone_new_identifier
which returns NULL on error instead of returning UTC
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 11 Sep 2025 11:20:24 +0000 (13:20 +0200)]
ch: Propagate lifecycle events
We already have a thread that listens on cloud-hypervisor's
monitor for incoming events and processes them. What is missing
though, is emitting of corresponding lifecycle events.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 10 Sep 2025 09:43:53 +0000 (11:43 +0200)]
ch: Unlock domain in virCHEventStopProcess() on all exit paths
The aim of virCHEventStopProcess() is to clean up after stopped
domain by calling virCHProcessStop(). But in order to do that it
needs to acquire a job and in order to do that it needs to lock
the domain object. Well, the object is not unlocked in all exit
paths, i.e. when job acquiring fails the domain object is left
locked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 10 Sep 2025 08:21:48 +0000 (10:21 +0200)]
ch: Avoid memory leak in virCHProcessEvents()
The aim of virCHProcessEvents() is to read data (in JSON format)
from CH monitor and then process them. To parse incoming data
virJSONValueFromString() is used. But the corresponding
virJSONValue is freed only when processing of an even succeeds.
If processing an event fails, then the memory is not freed
leading to a memory leak.
334 (24 direct, 310 indirect) bytes in 1 blocks are definitely lost in loss record 1,975 of 2,040
at 0x4919EF3: calloc (vg_replace_malloc.c:1675)
by 0x4FEB249: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x4A66162: virJSONValueNewObject (virjson.c:533)
by 0x4A67E74: virJSONValueFromJsonC (virjson.c:1413)
by 0x4A681A5: virJSONValueFromString (virjson.c:1484)
by 0xB8CD9D7: virCHProcessEvents (ch_events.c:179)
by 0xB8CDCDC: virCHReadProcessEvents (ch_events.c:251)
by 0xB8CDEBB: virCHEventHandlerLoop (ch_events.c:284)
by 0x4AC1EB4: virThreadHelper (virthread.c:256)
by 0x5441DE3: start_thread (in /usr/lib64/libc.so.6)
by 0x54C25F3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Mon, 25 Aug 2025 03:32:39 +0000 (23:32 -0400)]
conf: auto-add a pcie-root-port when needed while plugging in pcie-to-pci-bridge
This will almost surely never come up during any normal operation[*],
which is likely why this wasn't done when pcie-to-pci-bridge support
was added back in the before-fore times. It's pretty simple to support
though - a pcie-to-pci-bridge plugs into a pcie-root-port just like
any other pcie device, and if there isn't an open slot on an existing
pcie-root-port, we can just add one.
([*] in real life, a pcie-to-pci-bridge is only auto-added by libvirt
itself, while this function is dealing with the followup to *user
added* devices. Also each pcie-to-pci-bridge has 32 slots, and it's
unlikely a domain with pcie support would be wanting more than 32
conventional PCI (i.e. not PCIe) devices)
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Tue, 26 Aug 2025 18:41:32 +0000 (14:41 -0400)]
conf: improve error message when a PCI controller can't be auto-added
Log a slightly different message when the missing-but-required slot is
conventional PCI vs PCIe. Also correct/improve the comments about why
auto-add of a PCI controller isn't supported when we're trying to
create a slot for various different pci controllers.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Mon, 11 Aug 2025 06:11:25 +0000 (02:11 -0400)]
conf: add forgotten clause to virDomainPCIControllerConectTypeToModel()
When building the PCI topology of a domain that has PCI devices with
no assigned PCI addresses, the function virDomainPCIAddressSetGrow()
will attempt to add a new PCI controller with the appropriate type of
slot to connect a device that doesn't have a PCI address.
In some cases this isn't possible (for example, if the device you are
attempting to add to the topology requires a type of connection only
provided by some controller that *itself* requires a connection of a
type not available for the given architecture/machinetype, e.g. if you
want to add a pcie-root-port to a domain with a machine type that has
a pci-root (no PCIE)). In those cases, an error message is logged by
using virDomainPCIControllerConectTypeToModel() to extract the type of
device from the "flags" that are sent to virDomainPCIAddressSetGrow().
However, if virDomainPCIControllerConectTypeToModel() doesn't find a
device type in the connection flags, it will return -1, and
virDomainPCIAddressSetGrow() will log the very generic:
Cannot automatically add a new PCI bus for a device with connect flags nnnn
Both of these functions were written prior to libvirt adding support
for the pcie-to-pci-bridge controller, and when that support was added
(in 2018), a new if() clause wasn't added to
virDomainPCIControllerConectTypeToModel(). Seven (!) years later, this
omission was noticed by someone adding a new test case to regression
testing.
This patches remedies the earlier omission, so that now when someone
tries to add a pcie-to-pci-bridge controller to a domain that doesn't
have PCIE, the message will be:
a PCI slot is needed to connect a PCI controller model='pcie-to-pci-bridge', but none is available, and it cannot be automatically added
This is still not an ideal error message, but is arguably better.
(NB: Unfortunately it isn't possible to use a switch() statement with
no default case (in order to catch a similar error in the future),
since we are converting from bitmapped flags. Fortunately, we haven't
needed to add a new PCI controller type in the last 7 1/2 years :-)
Resolves: https://issues.redhat.com/browse/RHEL-62032 Fixes: 542f05e7756cc5614eb2ee7b0bac9aabb7aa016c Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Sat, 23 Aug 2025 04:09:41 +0000 (00:09 -0400)]
qemu: fix multiple missing setup/teardown of passt process for interface type='vhostuser'
passt networking support was originally added only for <interface
type='user'>, and all of the codepaths leading to qemuPasst*()
functions were protected with
if (net->type == VIR_DOMAIN_NET_TYPE_USER &&
net->backend.type == VIR_DOMAIN_NET_BACKEND_PASST)
When support was later added to use a vhost-user socket to connect
between the passt process and qemu process, *some* of the conditionals
similar to the above were changed to be
As a matter of fact, enough of these places were changed to make
passt+vhostuser work. However I missed a few places that resulted in
the passt process not being properly shutdown/cleaned up when the
interface type was vhostuser, and also as far as I can see from
examining the code, the passt process wasn't being added to the cgroup
for the domain.
We could fix these problems by adding the extra condition to all the
missing places (checking for either 'user' or 'vhostuser' as well as
for backend type of 'passt'), but since validation already guarantees
that if backend type='passt' then the interface type MUST be either
'user' or 'vhostuser', it's really just adding extra code for no good
purpose (and would leave open the possibility of the same problem
recurring in the future if a different interface type begins using
passt as well). So the better solution is to not bother checking
net->type at all in those locations - if backend type is 'passt' then
we call the passt-related code.
Resolves: https://issues.redhat.com/browse/RHEL-80285
Resolves: https://issues.redhat.com/browse/RHEL-92842 Fixes: 1e9054b9c79d721a55f413c2983c5370044f8f60 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
qemu: support setting guest hostname/fqdn using DHCP on passt-backed interfaces
This commit introduces support for configuring hostnames in virtual
machines (VMs) using DHCP via an interface backed by the passt
transport. This is done with the new 'hostname' and 'fqdn' (Fully
Qualified Domain Name) attributes in the <backend> subelement of
<interface>. The values set in these attributes are added to the passt
commandline for the interface (with the --hostname and --fqdn
options), and passt will then send the settings to the guest by adding
options to the DHCP response when the interface is started - for IPv4,
hostname will be sent in option 12, or the FQDN will be sent in option
81, and for IPv6 the FQDN will be sent using option 39.
This will enable a management application to easily configure guest
hostnames without intervening in the guest's disk image (as long as
the guest uses DHCP for it's network interface configuration).
Here is an example of setting the hostname and fqdn for a guest (in
practice, you would only use one or the other, since according to the
RFC if option 81 is sent to the guest, option 12 should not be sent).
ch: Avoid memleak on disk detach in chDomainRemoveDevice()
The aim of chDomainRemoveDevice() is to remove device from
virDomainDef. Well, in case of disks this is done by calling
virDomainDiskRemove() which merely just removes it from the array
of virDomainDiskDef-s but leaves it up to the caller to actually
free the disk def.
1,286 (560 direct, 726 indirect) bytes in 1 blocks are definitely lost in loss record 2,005 of 2,041
at 0x4919EF3: calloc (vg_replace_malloc.c:1675)
by 0x4FEB249: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x4AFD9A4: virDomainDiskDefNewSource (domain_conf.c:2409)
by 0x4B10ACA: virDomainDiskDefParseXML (domain_conf.c:8509)
by 0x4B24F07: virDomainDeviceDefParse (domain_conf.c:14631)
by 0xB8D8881: chDomainAttachDeviceLiveAndUpdateConfig (ch_hotplug.c:135)
by 0xB8CCFE0: chDomainAttachDeviceFlags (ch_driver.c:2376)
by 0xB8CD057: chDomainAttachDevice (ch_driver.c:2394)
by 0x4DC1C7D: virDomainAttachDevice (libvirt-domain.c:8951)
by 0x405E545: remoteDispatchDomainAttachDevice (remote_daemon_dispatch_stubs.h:3763)
by 0x405E495: remoteDispatchDomainAttachDeviceHelper (remote_daemon_dispatch_stubs.h:3742)
by 0x4BF3164: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the end of chDomainDetachDeviceLive() there's a code that
tries to remove the disk that's being detached from the domain
definition. Well, it's a leftover from the original patch which I
forgot to remove when rewriting it to use chDomainRemoveDevice().
The disk is removed there so this code has no chance in removing
it again. Drop the code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
ch: Actually remove device in chDomainDetachDeviceLive()
Inside of chDomainDetachDeviceLive() there are two variables that
are important in this case: 'match' and 'detach'. The first one
contains device definition as parsed from user provided XML, the
other contains pointer to the device definition inside
virDomainDef (as returned by chDomainFindDisk()).
Now, when chDomainRemoveDevice() is called, it looks up the
device inside virDomainDef and removes it (using pointer
comparison). Well, that means 'detach' must be passed as an
argument instead of 'match'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
When virCHDriverConfig struct is initialized in
virCHDriverConfigNew() the 'configDir' member is allocated but
corresponding free is missing in virCHDriverConfigDispose().
While at it, reorder the free calls to match the order in which
they are declared in the struct so it's easier to spot missing
free call.
20 bytes in 1 blocks are definitely lost in loss record 667 of 2,033
at 0x4912888: malloc (vg_replace_malloc.c:446)
by 0x5436747: __vasprintf_internal (in /usr/lib64/libc.so.6)
by 0x503EC81: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x500805B: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x5008124: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0xB8C2B70: virCHDriverConfigNew (ch_conf.c:181)
by 0xB8C9DDA: chStateInitialize (ch_driver.c:1456)
by 0x4D9E316: virStateInitialize (libvirt.c:667)
by 0x40539DB: daemonRunStateInit (remote_daemon.c:581)
by 0x4AC1EB4: virThreadHelper (virthread.c:256)
by 0x5441DE3: start_thread (in /usr/lib64/libc.so.6)
by 0x54C25F3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
ch: Implement VIR_DOMAIN_DESTROY_GRACEFUL flag support
The virDomainDestroyFlags() API has several flags, including
VIR_DOMAIN_DESTROY_GRACEFUL which is documented to send only
SIGTERM to the emulator process. Implement its support into CH
driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
A caller (e.g. chDomainDestroyFlags()) might want to chose
whether to kill emulator process forcefully or gracefully (the
@force argument of virProcessKillPainfully()). Invent a flag to
virCHProcessStop() for this. And to keep consistent behaviour,
pass the flag everywhere for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
ch: Make sure the cloud-hypervisor process is killed in virCHProcessStop()
Currently, virCHProcessStop() is called either when the
cloud-hypervisor process dies gracefully (e.g. on shutdown
initiated from within the guest) or when virDomainDestroy() is
called (or on failed start attempt, but that's not important
right now).
At any rate, if the cloud-hypervisor process is running it's not
a child process of libvirtd rather than the init (per
virCommandDaemonize() called inside of virCHMonitorNew()). This
distinction is important because virCHProcessStop() then calls
virProcessAbort() thinking it'll kill the process. Well,
virProcessAbort() works only on child processes.
Switch to virProcessKillPainfully() which does work in such
cases.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
virprocess: Report errno if virProcessAbort() fails
The aim of virProcessAbort() is to reap a child process. It does
so by waitpid()-ing and possibly sending SIGTERM/SIGKILL to the
child process (and waitpid()-ing again). Nevertheless, if
everything fails a debug message is printed. But the message
mentions only the PID and not errno (set by previous waitpid())
which may be useful. For instance when virProcessAbort() is
called over a PID that's not our child:
failed to reap child 16325, abandoning it: No child processes
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainDeviceInfoClear method does not free the struct, only
its contents, so all pointer fields must be explicitly set to NULL
after releasing to avoid disk of double-free.
Reported by coverity:
*** CID 895678: Memory - corruptions (USE_AFTER_FREE)
/src/conf/domain_conf.c: 5926 in virDomainDeviceInfoParseXML()
5920 goto cleanup;
5921
5922
5923 ret = 0;
5924 cleanup:
5925 if (ret < 0)
>>> CID 895678: Memory - corruptions (USE_AFTER_FREE)
>>> Calling "virDomainDeviceInfoClear" frees pointer "info->acpiNodeset" which has already been freed.
5926 virDomainDeviceInfoClear(info);
5927 return ret;
5928 }
5929
5930 static int
5931 virDomainHostdevSubsysUSBDefParseXML(xmlNodePtr node,
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Fri, 5 Sep 2025 08:10:12 +0000 (10:10 +0200)]
qemu: block: Always enable discard forwarding for 'throttle' filter layer
Discards ought to be forwarded to the protocol nodes where we control
if discard actually happens.
Unconditionally enable discard='unmap' for the intermediate layer.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/810 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 27 Aug 2025 06:36:08 +0000 (08:36 +0200)]
datatypes: Refactor rest of 'virGet*' helpers
Similarly to the refactor of 'virGetDomain' done in commit 3de56902d32
rework the code to assume that 'virObjectNew' can't return NULL and use
the 'virCheck*Return' helpers to avoid an 'error:' label.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'virGet*' helpers check that the passed objects which are used to
construct the new object are valid. The check that the 'conn' object in
'virStreamGet' was missing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Righi [Sat, 6 Sep 2025 13:09:02 +0000 (15:09 +0200)]
docs: Document acpi nodeset in hostdev
Add documentation for the new <acpi nodeset="..."> element in hostdev,
which allows associating devices with ACPI Generic Initiator objects in
QEMU.
A typical use case is NVIDIA Multi-Instance GPU (MIG), where a physical
GPU is partitioned into multiple isolated instances, each tied to one or
more virtual NUMA nodes. The documentation includes an example showing
how to configure <numa> cells together with a MIG device.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Andrea Righi <arighi@nvidia.com>
Andrea Righi [Sat, 6 Sep 2025 13:08:57 +0000 (15:08 +0200)]
qemu: Allow to define NUMA nodes without memory or CPUs assigned
Allow to define NUMA nodes without memory or CPUs assigned to properly
support the new acpi-generic-initiator device.
This is required because the NUMA nodes passed to the
acpi-generic-initiator object must be independent and not be shared with
other resources, such as CPU or memory.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Andrea Righi <arighi@nvidia.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:35 +0000 (14:10 +0200)]
NEWS: announce disk hotplug support for ch
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:34 +0000 (14:10 +0200)]
ch: implement disk device detach in public API
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 8 Sep 2025 12:56:04 +0000 (14:56 +0200)]
ch: add disk detach helper functions
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:33 +0000 (14:10 +0200)]
ch: add virCHMonitorRemoveDevice function
The function calls the respective CH API to remove a device of any type
from a VM.
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:32 +0000 (14:10 +0200)]
ch: add virCHMonitorBuildKeyValueJson
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:30 +0000 (14:10 +0200)]
ch: implement disk attach in public API
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:29 +0000 (14:10 +0200)]
ch: add disk attach helper functions
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:28 +0000 (14:10 +0200)]
ch: add monitor disk attach logic
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:27 +0000 (14:10 +0200)]
ch: add/use virCHMonitorPut function
This allows users to call API endpoints that require passing data in a
generic way. Previously, only virCHMonitorPutNoContent was offered.
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:26 +0000 (14:10 +0200)]
ch: refactor virCHMonitorBuildDiskJson
Refactor BuildDiskJson to return a virJSONValue instead of adding the
disk json to an json array. This makes the function reusable for
hotplugging disks.
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:24 +0000 (14:10 +0200)]
ch: pass disk alias to CHV
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:31 +0000 (14:10 +0200)]
ch: assign aliases in ProcessPrepareDomain
This is required to have unique device aliases for devices throughout
the domain lifecycle.
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:25 +0000 (14:10 +0200)]
ch: add ch_alias.{c,h} for device alias handling
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Thu, 4 Sep 2025 12:10:23 +0000 (14:10 +0200)]
ch: add ch_hotplug.{h,c} files to CH build
The files are meant to contain all device hotplug related code. The
first implementation will be live storage attach and detach.
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Ján Tomko [Tue, 2 Sep 2025 12:04:40 +0000 (14:04 +0200)]
esx: pass 'long' to curl_easy_setopt when needed
The include header got its type checks fixed in curl 8.14:
https://github.com/curl/curl/commit/79b4e56b3f30dc1ac28a81128a07d27338e5219e
https://github.com/curl/curl/pull/17143
This causes a warning on rawhide with clang:
../src/esx/esx_vi.c:318:5: error: call to '_curl_easy_setopt_err_long'
declared with 'warning' attribute: curl_easy_setopt expects a long
argument [-Werror,-Wattribute-warning]
318 | curl_easy_setopt(curl->handle, CURLOPT_NOSIGNAL, 1);
| ^
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemu: Don't query unavailable-features if qom-list-get is supported
With qom-list-get we already have the value of unavailable-features
property in the returned object (just like we have all values of all
bool properties). Let's use the value from there instead of querying for
it separately using qom-get.
After this patch only a single QMP command is used for getting all the
required info about guest CPUs created by QEMU 10.1 or newer.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Mon, 25 Aug 2025 14:16:49 +0000 (16:16 +0200)]
qemu: Use qom-list-get for checking enabled CPU features
qom-list-get is a new QMP command (since QEMU 10.1) that combines
qom-list for listing properties of a specified object with qom-get for
getting a value of a given property. The new command provides an array
of all properties and their values, which allows us to dramatically
reduce the number of QMP commands we have to call when starting a domain
to check which CPU features were actually enabled.
A simple domain with no disk can now be started with only 15 QMP
commands in about 200 ms compared to 485 commands and 400 ms startup
time without this patch.
https://issues.redhat.com/browse/RHEL-7038
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 27 Aug 2025 12:38:24 +0000 (14:38 +0200)]
qemu: Parse properties list from any JSON array
The qemuMonitorJSONParsePropsList API expected a QMP reply as an input.
By generalizing it to work on any JSON array, we can reuse the API even
for commands which return the array of properties nested in an object.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 27 Aug 2025 10:29:57 +0000 (12:29 +0200)]
qemu: Move feature filtering to qemuMonitorJSONGetCPUProperties
When getting enabled CPU features (qemuMonitorJSONGetCPUData), we used
to call qemuMonitorJSONGetCPUProperties to get the list of all boolean
properties and then queried their values and ignored properties that
were not true. By moving the filtering inside
qemuMonitorJSONGetCPUProperties we don't need to even add disabled
features to any list and also get ready for better QMP interface.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 27 Aug 2025 08:05:23 +0000 (10:05 +0200)]
qemu: Generalize filtering in qemuMonitorJSONParsePropsList
qemuMonitorJSONParsePropsList supported filtering based on type. Let's
replace it with a callback supplied by the caller to allow for more
advanced filtering.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Mon, 25 Aug 2025 14:36:01 +0000 (16:36 +0200)]
qemu: Drop legacy probing of CPU features
The legacy probing which reads CPUID registers from QEMU and interprets
the individual bits is not used with any QEMU version currently
supported by libvirt. The code would only be used if
QEMU_CAPS_CPU_UNAVAILABLE_FEATURES capability (detected by probing the
presence of 'unavailable-features') was missing on x86, but all QEMU
release we care about report unavailable-features on x86.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Hector Cao [Wed, 27 Aug 2025 14:25:06 +0000 (16:25 +0200)]
docs : add doc on cpu model and features
Add documentation on the way libvirt displays the Host CPU
model and capabilities (features). There is an implicit
expectation from users to get the CPU model name matching the
CPU model they are running on, however, this does not happen
most of the time. As a consequence, having a documentation
is useful both for users to align their expectation and for
us to point to a place where the situation is clearly explained.
Signed-off-by: Hector Cao <hector.cao@canonical.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Peter Krempa [Fri, 29 Aug 2025 13:10:36 +0000 (15:10 +0200)]
scripts: qemu-replies-tool: Add stable dump of 'query-command-line-options'
While 'query-command-line-options' is usually fairly stable (for
comparing between two .replies files) it's simpler to compare it in the
dumped variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 15:02:04 +0000 (17:02 +0200)]
scripts: qemu-replies-tool: Prefix output with filename when dumping data for multiple files
The --dump-* mode can be used together with --repliesdir which iterates
over all '.replies' files in the directory. Make this useful by
outputing the filename so the user can associate the data with the file
it was dumped from.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 14:41:36 +0000 (16:41 +0200)]
scripts: qemu-replies-tool: List also data from 'qom-list-properties'
In addition to 'device-list-properties' libvirt probes also some
properties of qom types. Since the format is identical make the dumping
function for 'device-list-properties' universal and make it accept also
'qom-list-types'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 14:13:09 +0000 (16:13 +0200)]
scripts: qemu-replies-tool: Drop specific invocation of marginally useful dump modes
While '--dump-qmp-query-strings' is useful by itself because it's a
simple way to generate the QMP schema query strings for libvirt, the
other modes aren't useful besides comparing two .replies files by the
dumped output.
Remove specific options for '--dump-qom-list-types' and
'--dump-device-list-properties', so that upcoming additions which will
be useful only for comparisons aren't forced to add these options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 12:30:56 +0000 (14:30 +0200)]
scripts: qemu-replies-tool: Convert the QMP conversation to list of dicts
Currently the conversation was a list of tuples. Since upcoming patches
will want to store some additional flags with the processed commands
convert it to a list of dicts, so that we can name the individual
fields.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 27 Aug 2025 08:44:55 +0000 (10:44 +0200)]
qemucapabilitiestest: Add data for the qemu-10.2 dev cycle
This is an extremely early addition with data as of v10.1.0-1-ge771ba98de
thus effectively no code change compared to the qemu-10.1 release.
This early addition is done since I've upgraded the computer I'm
capturing the dumps from (yes the dumps are host-specific, and there
isn't really a good option if we want to have modern CPU data around).
Thus the only difference in the output files comes from the CPU change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 27 Aug 2025 14:34:39 +0000 (16:34 +0200)]
qemuxmlconftest: Rename and strip specific machine type from 'x86_64-default-cpu-*' cases
qemu-10.2 which we're about to add capabilities dump for will remove the
'4.2' machine type per deprecation policy.
The 'x86_64-default-cpu-*' still reference it. Since there is no
functional difference when upgrading the tests to the latest machine
type (pc/q35 alias as handled internally by qemuxmlconftest) let's
rename and modernize these.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 15:38:52 +0000 (17:38 +0200)]
qemu: capabilities: Detect TPM related capabilities from 'qom-list-types'
All the information needed to detect supported TPM front and backends
is present in the QOM types we already query, thus we don't need to
invoke specific commands for querying TPM stuff.
The only discrepancy is that there are 3 versions of 'tpm-tis' based on
the backed they use.
This patch reworks the probing but keeps the query commands in place.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 Aug 2025 13:11:07 +0000 (15:11 +0200)]
qemu: capabilities: Drop probe of 'query-migrate-capabilities'
There is currently noting being probed from the reply of the command. In
addition in most cases a feature can be now probed via the QMP schema
which covers the return values in 'query-migrate-capabilities'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
