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>
Peter Krempa [Fri, 7 Mar 2025 16:37:26 +0000 (17:37 +0100)]
conf: Drop support for 'sheepdog' disks
In upcoming patches we'll update minimum supported qemu version to
qemu-6.2 which no longer supports 'sheepdog'. This was the only
hypervisor driver that supported it.
Reject any config containing sheepdog disks when validating the XML,
remove the positive test cases in qemu and replace them by a negative
test case. This will still excercise the XML schema, but will prepare
for removal of the internal code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
util: netdevvlan: Change return type of virNetDevVlanCopy to void
This function return value is invariant since 1022e0ee, so change
its type and remove all dependent checks.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Alexander Rudyuk <a.rudyuk@fobos-nt.ru> Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Pavel Hrdina [Thu, 6 Mar 2025 11:55:25 +0000 (12:55 +0100)]
domain_conf: graphics: properly escape user provided strings when formatting XML
This was reported on virt-manager issue tracker as it was possible to
provide `listen` attribute with properly escaped characters but libvirt
would format XML without escaping it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/748 Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: introduce 'raw' and 'rawset' ACPI table types
The QEMU driver has only accepted type=slic even though QEMU is able to
accept individual tables of any type, without needing to specify a
signature. Introduce type=raw to address this usage scenario. Contrary
to other types, this one may appear multiple times.
The Xen driver has mistakenly accepted type=slic and use it to set the
Xen acpi_firmware setting, which performs a simple passthrough of
multiple concatenated data table. Introduce type=rawset to address
this usage scenario.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
into a flat 'char *slic_table' field which is rather an anti-pattern
as it has special cased a single attribute type.
This rewrites the internal design to permit multiple table types to
be parsed, should we add more in future. Each type is currently
permitted to only appear once.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Dion Bosschieter [Tue, 18 Feb 2025 14:56:32 +0000 (15:56 +0100)]
nwfilter: Fix deadlock between nwfilter-list and VM startup/migration
The `nwfilterBindingCreateXML` and `nwfilterConnectListAllNWFilters`
APIs can acquire locks on multiple instances of virNWFilterObj. There
is no guarantee they will acquire these locks in the same order as
each other. Thus there is a potential for deadlock if they run
concurrently acquiring locks on the same filter objects.
This flaw has always existed, but historically was rare, because
virNWFilterObjList previously used an array. This meant iteration
over filters had a fixed order, matching order of loading filters
into libvirt. The set of filter references would have to be just
right to expose the lock ordering deadlock.
In 8.2.0, commit c4fb52dc72b312431a3a28e3a163b38441a95665 switched
to use a hash table, introducing non-determinism to the iteration
order, as hash buckets vary based on the hash seed. As such almost
any filter with references is exposed to the deadlock risk now.
It is not easy to guarantee lock ordering on the virNWFilterObj
instances, so acquiring `driverMutex` first, will serve to serialize
all lock acquisition on virNWFilterObj instances, avoiding the
deadlock scenario.
The major cost is that concurrency of the driver is significantly
reduced, with few other APIs able to run in parallel with updating
firewall rules.
A long term solution to this problem needs significant changes
* The mutex on virNWFilterObj would need to change to a R/W
lock.
* The filter instantiation/teardown process would need to split
into two phases. The first phase would resolve all the required
virNWFilterObj instances & acquire read locks, while holding
the 'driverMutex'. The second phase of running iptables/ebtables
commands would then run without driverMutex held.
* The filter define/undefine APIs would need to acquire write
locks, other APIs only read locks.
This would allow concurrency of filter instantiation/teardown
with everything except for filter defnie/undefine, which was
the original desire.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[DPB: rewrite commit message & add inline comment] Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
Peter Krempa [Tue, 4 Mar 2025 11:46:33 +0000 (12:46 +0100)]
qemuxmlconftest: Add '+amdsev' versions of the rest of 'launch-security-sev*' cases
While the 'launch-security-sev-direct' and 'launch-security-sev-snp'
cases use "latest" caps, they use the non-sev variant and add-in the
relevant capabilities.
To do the test properly we can add '+amdsev' variant which uses caps
fetched from a real host that does support all the capabilities.
The output files are identical, although they are not added as symlinks
to prevent headaches if they do diverge at some point.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Tue, 4 Mar 2025 11:46:33 +0000 (12:46 +0100)]
qemuxmlconftest: Add 'latest' version of 'launch-security-sev*' originally using 6.0.0
The 'launch-security-sev' and
'launch-security-sev-missing-platform-info' tests run agains the
qemu-6.0.0 caps which were manually doctored to support SEV.
Since we now have the '+amdsev' variant dumped from a more modern qemu
add another invocation of the tests.
The only relevant difference in the output data is 'cbitpos' being '51'
on the new platform, for the test case which explicitly doesn't
configure it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Tue, 4 Mar 2025 09:56:23 +0000 (10:56 +0100)]
qemuxmlconftest: Propery discriminate output files for caps variants
While the 'qemuxmlconftest' was able to load capability variants the
output file name didn't include the variant thus it was not possible to
test the same input file both on the default variant and on an explicit
variant.
Include the variant in the output file name and adjust two output file
names.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Tue, 4 Mar 2025 08:41:02 +0000 (09:41 +0100)]
domaincapstest: Allow tests of all capability variants
Currently only the default variant ("") and "+hvf" are present in our
test data but upcoming patches will add another variant.
Upcoming test variants may not require any special handling so we should
be able to handle them using the default code path now that 'variant' is
properly propagated inside the test code.
Remove the restriction to test only the default ("") and "+hvf" variant
and modify the documentation to state that any other variant is tested
the same way as the default one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 3 Mar 2025 17:18:06 +0000 (18:18 +0100)]
domaincapstest: Use proper input file based on 'variant' in 'fillQemuCaps'
The qemu part of 'domaincapstest' supports testing of the '+hvf' variant
of files, but doesn't properly pick the input file. The input file lacks
the variant part thus the wrong file is used.
Propagate the variant and select the correct input file.
Fixes: 738c5bae888cfa72ed359899cf1a41fed9dbb0f5 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
projects / thirdparty / libvirt.git / log
