Right now we expect the configuration files for init scripts
to live in /etc/sysconfig, but that location is only used by
RHEL- and SUSE-derived distros.
This means that packagers for other distros have to patch
things as part of the build process, while people building
from source will get wonky integration.
This new option will provide a convenient way to override
the default location at build time that is usable by distro
packagers and people building from source alike.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Now that a version of GLib that contains the fix has been
released, it's more useful to record that information. Adding
a TODO annotation makes the whole thing easily greppable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The spelling is slightly different from another otherwise
identical error message in the same file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
At this moment it is not possible to launch a 'riscv64' domain if a CPU
definition is presented in the domain. For example, adding this CPU
definition:
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>rv64</model>
</cpu>
Will trigger the following error:
$ sudo ./run tools/virsh start riscv-virt1
error: Failed to start domain 'riscv-virt1'
error: this function is not supported by the connection driver:
cannot update guest CPU for riscv64 architecture
The error comes from virCPUUpdate(), via qemuProcessUpdateGuestCPU(),
and it's caused by the absence of the 'update' API in the existing
RISC-V driver.
Add an 'update' API impl to the RISC-V driver to allow for CPU
definitions to be declared in RISC-V domains. This API was copied from
the ARM driver (virCPUarmUpdate()) since it's a good enough
implementation to get us going.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The current values might have been accurate at the time
when the logic was introduced, but these days Arch is
using the same ones as Debian.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat>
Switch from int to double for displaying job progress upto 2 decimal
places.
Signed-off-by: Shaleen Bathla <shaleen.bathla@oracle.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Implement the support for the persisted poll parameters and remove
restrictions on saving config when modifying them during runtime.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we allow configuring the 'poll-max-ns', 'poll-grow', and
'poll-shrink' parameters of qemu iothreads only during runtime and they
are not persisted. Add XML machinery to persist them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemu driver now accepts also _ULLONG as type for bigger numbers. Use
the 'virTypedParamListAddUnsigned' helper to use the bigger typed
parameter type if necessary to allow full range of the values while
preserving compatibility.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the internal types to unsigned long long. Luckily we can also
covert the external types too:
- 'qemuDomainSetIOThreadParams' can accept both _UINT and _ULLONG by
converting to 'virTypedParamsGetUnsigned'
- querying is handled via the bulk stats API which is flexible:
- we use virTypedParamListAddUnsigned to use the bigger type only if
necessary
- most users don't even notice because the bindings abstract the
data types
Apart from the code modifications we also improve the documentation
which was missing for the setters.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU accepts even values bigger than INT_MAX. The reasoning for these
checks was that the QAPI definition declares them as 'int', but in QAPI
terms that's any number as it's JSON.
Remove the validation as well as the comment misinterpreting the QAPI
definiton.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor to use the new data type so that we can use the APIs of it in
upcoming patches.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For certain typed parameters we want to extend the supproted range by
switching to VIR_TYPED_PARAM_ULLONG. To preserve compatibility we've
added APIs such as 'virTypedParamsGetUnsigned' and
'virTypedParamListAddUnsigned' which automatically select the bigger
type if necessary.
This patch adds a new internal macro VIR_TYPED_PARAM_UNSIGNED which
is used with virTypedParamsValidate to allow both types and adjusts the
code to handle it properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use automatic memory cleanup for the 'keys' and 'sorted' helpers and
remove the 'cleanup' label. Since this patch is modifying variable
declarations ensure that all declarations conform with our coding style.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an internal helper for fetching a typed parameter which can be
either of the '_UINT' or '_ULONG' type and store it in a unsigned long
long variable.
Since this is an internal helper it offers less protections against
invalid use compared to those we expose as public API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new helper adds a unsigned value, stored as _UINT if it fits into
the type and stored as _ULLONG otherwise.
This is useful for the statistics code which is quite tolerant to
changes in type in cases when we'll need more range for the value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function now return always 0. Refactor the code and remove return
values.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only non-abort()-ing error which can happen is if the field name is
too long. Store the overly long name in the virTypedParamList container
so that in upcoming patches the helpers adding to the list can be
refactored to not have a return value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Return the number of parameters via pointer passed as argument to free
up possibility to report errors. Strangely all callers actually use
'int' as type for storing the count of elements, thus this function will
use the same.
The function is also renamed to virTypedParamListSteal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a helper that fetches the typed parameters from the list while
still preserving ownership of the pointer by the list.
In the future this will be also able to report errors stored in the
list.
Signed-off-by: Peter Krempa <pkrempa@redhat.com
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The struct will be made private in upcoming patches. Construct the list
of block entries into a separate list and append them rather than
remember the index of the count element.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Introduce a helper function to concatenate two virTypedParamLists. This
will allow us to refactor qemuDomainGetStatsBlock to not access the list
directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Add an allocator function and refactor all allocations to use it. In
upcoming patches 'struct _virTypedParamList' will be made private.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The header uses both styles randomly, switch it to the contemporary
style.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Don't check the return value of 'virTypedParamListExtend' which will
always be a valid pointer and 'virTypedParameterAssignValue' always
returns 0.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There are two callers of virTypedParameterAssignValueVArgs.
- 'virTypedParameterAssignValue' always uses the correct type, thus
doesn't need to be modified. Just use the proper type in the function
declaration
- 'virTypedParameterAssign' can get improper type, but we can move the
validation into it decreasing the scope in which failures need to be
propagated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
All changed lines even fit into 80 columns.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Ensure that all switch statements in this module use the proper type in
switch() statements to ensure complier protections.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
All callers pass 'true'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Update the news file mentioning important changes such as the change of
translatable strings or the fix of inactive snapshots of VMs using uefi.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Repeatedly querying an SR-IOV PCI device's capabilities exposes a
memory leak caused by a failure to free the virPCIVirtualFunction
array within the parent struct's g_autoptr cleanup.
Valgrind output after getting a single interface's XML description
1000 times:
==325982== 256,000 bytes in 1,000 blocks are definitely lost in loss record 2,634 of 2,635
==325982== at 0x4C3C096: realloc (vg_replace_malloc.c:1437)
==325982== by 0x59D952D: g_realloc (in /usr/lib64/libglib-2.0.so.0.5600.4)
==325982== by 0x4EE1F52: virReallocN (viralloc.c:52)
==325982== by 0x4EE1FB7: virExpandN (viralloc.c:78)
==325982== by 0x4EE219A: virInsertElementInternal (viralloc.c:183)
==325982== by 0x4EE23B2: virAppendElement (viralloc.c:288)
==325982== by 0x4F65D85: virPCIGetVirtualFunctionsFull (virpci.c:2389)
==325982== by 0x4F65753: virPCIGetVirtualFunctions (virpci.c:2256)
==325982== by 0x505CB75: virNodeDeviceGetPCISRIOVCaps (node_device_conf.c:2969)
==325982== by 0x505D181: virNodeDeviceGetPCIDynamicCaps (node_device_conf.c:3099)
==325982== by 0x505BC4E: virNodeDeviceUpdateCaps (node_device_conf.c:2677)
==325982== by 0x260FCBB2: nodeDeviceGetXMLDesc (node_device_driver.c:355)
Signed-off-by: Tim Shearer <tshearer@adva.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This fixes cross-building in some scenarios.
Specifically, when building for armv7l on x86_64, has_header()
will see the x86_64 version of the linux/kmv.h header and
consider it to be usable. Later, when an attempt is made to
actually include it, the compiler will quickly realize that
things can't quite work.
The reason why we haven't hit this in our CI is that we only ever
install the foreign version of header files. When building the
Debian package, however, some of the Debian-specific tooling will
bring in the native version of the Linux headers in addition to
the foreign one, causing meson to misreport the header's
availability status.
Checking for actual usability, as opposed to mere presence, of
headers is enough to make things work correctly in all cases.
The meson documentation recommends using has_header() instead of
check_header() whenever possible for performance reasons, but
while testing this change on fairly old and underpowered hardware
I haven't been able to measure any meaningful slowdown.
https://bugs.debian.org/1024504
Suggested-by: Helmut Grohne <helmut@subdivi.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This removes minor version number from OpenSUSE LEAP target names
and on CentOS Stream 9 installs flake8 from repositories, instead
of pip.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We no longer link to it from anywhere, and a server-side
redirect has been created to keep existing external links
working.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
All the information from java.rst have been transferred
to the subproject's own website.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
After previous cleanups, qemuHostdevPreparePCIDevices() no longer
needs virQEMUCaps. Drop its passing from callers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
After previous cleanup, there are some functions that do nothing:
qemuConnectDomainXMLToNativePrepareHostHostdev()
qemuConnectDomainXMLToNativePrepareHost()
qemuProcessPrepareHostHostdev()
qemuProcessPrepareHostHostdevs()
Remove them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When preparing a SCSI <hostdev/> with passthrough of a host SCSI
adapter (i.e. no protocol), a virStorageSource structure is
initialized and stored inside virDomainHostdevDef. But the source
structure is filled in many places, with almost the same code.
Firstly, qemuProcessPrepareHostHostdev() and
qemuConnectDomainXMLToNativePrepareHostHostdev() are the same.
Secondly, qemuDomainPrepareHostdev() allocates the src structure,
only to let qemuProcessPrepareHostHostdev() fill src->path later.
Well, src->path can be filled at the same place where the src
structure is allocated (qemuDomainPrepareHostdev()) which renders
the other two functions needless.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There is no way the qemuDomainAttachHostPCIDevice() function can
be called over a hostdev with PCI backend other than VFIO. And
even if it were, then the check is written so poorly that it lets
some types through (e.g. KVM) only to let
qemuBuildPCIHostdevDevProps() called afterwards fail properly.
Drop this check and rely on qemuDomainPrepareHostdevPCI() (and
worst case scenario even qemuBuildPCIHostdevDevProps()) to report
the proper error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
We used to support KVM and VFIO style of PCI assignment. The
former was dropped in v5.7.0-rc1~103 and thus we only support
VFIO. All other backends lead to an error (see
qemuBuildPCIHostdevDevProps(), or qemuBuildPCIHostdevDevStr() as
it used to be called in the era of aforementioned commit).
Might as well report the error in prepare phase and save hassle
of proceeding with device preparation (e.g. in case of hotplug
overriding the device's driver, setting seclabels, etc.).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
