ch: Fix refcounting in virCHEventHandlerLoop() and virCHStartEventHandler()
When event handler thread is created inside of
virCHStartEventHandler() the monitor object is refed because the thread
(virCHEventHandlerLoop()) that's created in the very next step
uses it. But right after that, the monitor object is unrefed,
which is wrong because it takes away the reference which was
handed over to the thread. The monitor must be unrefed inside the
thread, when no longer needed.
And while at it, move the unref call of the domain object after
the debug print which obviously accesses the domain definition.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If starting a CH domain fails an error is reported and
virCHProcessStart() calls virCHProcessStop() to clean up any
residues. Problem is, inside of virCHProcessStop() some public
APIs might be called (e.g. virNetworkLookupByName(),
virNetworkPortLookupByUUID() and/or virNetworkPortDelete()). Per
our design, public APIs reset last error which means the useful
error reported earlier is lost.
Fix this by calling virErrorPreserveLast() + virErrorRestore()
combo inside of virCHProcessStop().
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The glib adoption docs was suggesting avoidance of certain APIs that
were obsoleted by glib, during the transition period. Now that the
referenced APIs no longer exist in libvirt code, they can also be
removed from the docs.
NB, the virStringListRemoveDuplicates method remains since there is
no glib equivalent.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Most, but not all, files in scripts have execute permission. While we
don't need this in order to launch them via meson/ninja build rules,
it is nice to direct execution if they have execution permission. This
makes the practice consistent across all scripts.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
docs: document workaround for DMARC countermeasures
If a contributor's email domain has a DMARC policy of 'p=quarantine'
or 'p=reject', mailman will apply DMARC countermeasures on all mails
sent to lists.libvirt.org rewriting the "From" header to remove the
sender's email address. e.g.
From: Your Name via <lists.libvirt.org>
If these countermeasures were not applied, affected mail would either
have gone directly to SPAM, or have been entirely rejected. Mailman3
is unable to be configured to guarantee no mangling of the mail body
so these countermeasures are unavoidable for lists.libvirt.org.
Amongst the various downsides, the From address rewriting has the
bad effect of mangling git commit author attribution.
To avoid this it is required to add two additional git config
settings:
Note, *both* are required, even if your ``format.from`` matches
your existing git identity, because the latter only takes effect
once the former is set.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Laine Stump [Fri, 7 Mar 2025 00:19:12 +0000 (19:19 -0500)]
conf: parse interface/source/@dev for all interface types (with backend type='passt')
The original implementation of the passt backend for vhost-user
interfaces erroneously forgot to parse:
<source dev='blah'/>
for interface type='vhostuser', so it wasn't being added to the passt
commandline, and also wasn't being saved to the domain config. Now we
parse it whenever the <backend> type='passt', no matter what the
interface type, and then throw an error during validation if
source/@dev was specified for interface type = 'user|vhostuser' and
backend type != 'passt'.
Fixes: 1e9054b9c79d721a55f413c2983c5370044f8f60
Resolves: https://issues.redhat.com/browse/RHEL-82539 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Stefan Berger [Mon, 16 Dec 2024 19:16:44 +0000 (14:16 -0500)]
docs: Clarify what source and name attributes of TPM profile describe
Clarify what source and name attributes of TPM profile describe and
update the version placeholder to the libvirt version when profiles
were first supported, v10.10. Also mention that profiles with prefix
'custom:' in their name can be modified.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:03:02 +0000 (13:03 +0100)]
ch: Rework virCHProcessConnectMonitor()
Firstly, let's switch from explicit virCHDriverGetConfig() +
virObjectUnref() combo to g_autoptr(virCHDriverConfig). This
leaves us with the @monitor variable which is initialized to NULL
only to be then set to the retval of virCHMonitorNew() and
returned instantly. Well, the variable is now useless and can be
dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:02:33 +0000 (13:02 +0100)]
ch: Unref @cfg in virCHProcessStop()
At the beginning of virCHProcessStop() the ref to driver config
is obtained (via virCHDriverGetConfig()), but corresponding unref
call is lacking. Use g_autoptr() to make sure the config is
unrefed always.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:02:17 +0000 (13:02 +0100)]
ch: Free @iothreads array in virCHProcessSetupIOThreads()
When the CH driver starts a domain virCHProcessSetupIOThreads()
is called eventually which in turn calls
virCHMonitorGetIOThreads(). The latter returns an array of
iothreads which is never freed leading to a memleak:
130 (104 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 1,804 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0xB3A9359: virCHMonitorGetIOThreads (ch_monitor.c:1183)
by 0xB3AA5BB: virCHProcessSetupIOThreads (ch_process.c:348)
by 0xB3AAC59: virCHProcessSetup (ch_process.c:480)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:58 +0000 (13:01 +0100)]
ch: Don't leak virCHDomainObjPrivate struct members
There are some members of the virCHDomainObjPrivate struct that
are allocated at various stages of domain lifecycle but then are
never freed:
1) cgroup - allocated in virDomainCgroupSetupCgroup()
2) autoCpuset - this one is actually never allocated (and thus is
always NULL, but soon it may be used. Just free
it for now, which is a NOP anyways.
3) autoNodeset - same story as 2).
There are two more members, which shouldn't be freed:
1) driver - this is just a raw pointer to the CH driver (see
virCHDomainObjPrivateAlloc()).
2) monitor - this member is cleared in virCHProcessStop(), way
before control even gets to
virCHDomainObjPrivateFree().
452 (400 direct, 52 indirect) bytes in 1 blocks are definitely lost in loss record 1,944 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x49479CE: virCgroupNewFromParent (vircgroup.c:893)
by 0x49481BA: virCgroupNewDomainPartition (vircgroup.c:1068)
by 0x494915E: virCgroupNewMachineManual (vircgroup.c:1378)
by 0x49492FE: virCgroupNewMachine (vircgroup.c:1432)
by 0x4B5E3DE: virDomainCgroupInitCgroup (domain_cgroup.c:377)
by 0x4B5E9CD: virDomainCgroupSetupCgroup (domain_cgroup.c:524)
by 0xB3AC693: virCHProcessStart (ch_process.c:951)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:44 +0000 (13:01 +0100)]
ch: Free retval of curl_slist_append()
There are two places where curl_slist_append() is called but
corresponding call to curl_slist_free_all() is missing:
virCHMonitorPutNoContent() and virCHMonitorGet() which leads to
memleaks:
41 (16 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 992 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7B41: virCHMonitorPutNoContent (ch_monitor.c:824)
by 0xB3A89FF: virCHMonitorBootVM (ch_monitor.c:1030)
by 0xB3AC6F1: virCHProcessStart (ch_process.c:967)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
by 0x4B28B5E: virNetServerProcessMsg (virnetserver.c:135)
88 (16 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 1,501 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7E41: virCHMonitorGet (ch_monitor.c:864)
by 0xB3A92E2: virCHMonitorGetInfo (ch_monitor.c:1157)
by 0xB3A9CEA: virCHProcessUpdateInfo (ch_process.c:142)
by 0xB3AAD36: virCHProcessSetup (ch_process.c:492)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:19 +0000 (13:01 +0100)]
network: Free inhibitor in networkStateCleanup()
The shutdown inhibitor is created in networkStateInitialize() but
corresponding call to virInhibitorFree() is missing in
networkStateCleanup() leading to a memleak:
116 (72 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 1,769 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x4993B9B: virInhibitorNew (virinhibitor.c:152)
by 0x5279394: networkStateInitialize (bridge_driver.c:654)
by 0x4CC74DC: virStateInitialize (libvirt.c:665)
by 0x15B719: daemonRunStateInit (remote_daemon.c:613)
by 0x49F2B44: virThreadHelper (virthread.c:256)
by 0x5356662: start_thread (in /usr/lib64/libc.so.6)
by 0x53D7DA3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 12 Mar 2025 16:04:04 +0000 (17:04 +0100)]
qemu: Always assume support for QEMU_CAPS_INCREMENTAL_BACKUP
The support for incremental backup (not the backup api itself) was gated
on support for migrating bitmaps. As the ability to migrate bitmaps was
added in qemu-6.0 we can now assume that all supported qemu versions
support incremental backup.
Remove the interlocking.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 12 Mar 2025 15:19:12 +0000 (16:19 +0100)]
util: Drop 'virQEMUBuildCommandLineJSONArrayBitmap'
It was used to convert JSON arrays in legacy -object commandline
conversion. Since we now exclusively use JSON with -object, this
infrastructure is no longer needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 20 Feb 2025 15:33:59 +0000 (16:33 +0100)]
docs: formatdomain: Clarify configuration of iothread <-> virtqueue mapping
Add an example for the automatic/round-robin mapping of iothreads which
users should preferrably use. Until now the example contained even the
full mapping which could push users to use that instead.
Mention that the queues are then automatically distributed among the
iothreads.
Also clarify the need to set 'queues' when mapping threads explicitly
and how the queues are identified.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The checks in qemuProcessStartWarnShmem are no longer current. Since
previous patch made it fatal for vhost-user interfaces to be configured
without shared memory this warning code can be deleted.
Resolves: https://issues.redhat.com/browse/RHEL-80533 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 26 Feb 2025 15:55:54 +0000 (16:55 +0100)]
qemuDomainGetLaunchSecurityInfo: Don't forget unlock VM object on (impossible) error
If 'vm->def->sec->sectype' would be invalid; which is currently not
possible; we'd not unlock the domain object. Fix the logic even when the
bug currently can't happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
src: document that no constants are provided for custom VM stats
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'dirtyrate.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'memory.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'iothread.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'perf.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'block.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'net.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'vcpu.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'balloon.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'cpu.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for domain stats 'state.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'load.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'if.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'disk.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'fs.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constant for the guest info 'hostname' parameter
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'timezone.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'os.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add constants for guest info 'user.' parameters
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Tue, 11 Mar 2025 12:49:21 +0000 (13:49 +0100)]
security: Don't stop restoring labels too early
The point of virSecurityManagerRestoreAllLabel() function is to
restore ALL labels and be tolerant to possible errors, i.e.
continue restoring seclabels and NOT return early.
Well, in two implementations of this internal API this type of
problem was found:
1) virSecurityDACRestoreAllLabel() returned early if
virSecurityDACRestoreGraphicsLabel() failed, or when
def->sec->sectype equals to an impossible value.
2) virSecuritySELinuxRestoreAllLabel() returned early if
virSecuritySELinuxRestoreMemoryLabel() failed.
Fix all three places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
With a specific combination of compiler options gcc reported the
following bogus warning (I added a context to it to make the issue
visible):
../src/esx/esx_vi.c: In function ‘esxVI_LookupHostScsiTopologyLunListByTargetName’:
../src/esx/esx_vi.c:4674:32: error: potential null pointer dereference [-Werror=null-dereference]
4671 | if (!found || !hostScsiTopologyTarget)
4672 | goto cleanup;
4673 |
4674 | if (!hostScsiTopologyTarget->lun) {
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~
Most likely this is caused by found and hostScsiTopologyTarget doing
essentially the same thing as found is true if and only if
hostScsiTopologyTarget is non-NULL. The found variable is completely
redundant. Removing it would be enough, but I decided to make the code a
little bit easier to read by not using the iterator variable directly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virStringFormatHex converts an input byte array into hex string and
returns it.
Signed-off-by: Praveen K Paladugu <praveenkpaladugu@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-68043 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In its commit v9.2.0-323-ga5bd044b15 QEMU introduced another
command line option: -shim. It's used to load kernel. Track
presence of it via QEMU_CAPS_MACHINE_SHIM.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
For secure boot environments where <loader/> is signed, it may be
unfeasible to keep the binary up to date (esp. when revoking
certificates contained within). To address that, QEMU introduced
'-shim' cmd line option which side loads another UEFI binary
which can then contain new certification authorities or list of
revocations. Expose it as <shim/> element that's nested under
<os/>, just like kernel and initrd are.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Fri, 7 Mar 2025 16:00:12 +0000 (17:00 +0100)]
qemucapabilitiesdata: Drop un-updated 'qemu_6.2.0_aarch64' data
We'll be bumping to qemu-6.2 as minimum and the aarch64 qemu-6.2 data
were not updated to the release version. Drop them instead of trying to
do archaeology.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / thirdparty / libvirt.git / log
