Minor rewording to clarify purpose of the -C flag in the ninja
invocation, whilst retaining previous meaning.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the explicit meson "setup" command instead of the deprecated
implicit invocation. The implied setup usage generates a warning with
meson version 1.0.1:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Additionally the implicit command is likely to be confusing to those
unfamiliar with Meson - the `build` argument in `meson build` resembles
an action rather than an arbitrary path.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Suggest that new contributors should review past patch submissions for
typical style, feedback etc. prior to submitting. Link to archives.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the preparing patches section, note that it is possible to run CI
tests via gitlab prior to submitting patches.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clarify that patches should apply cleanly to the master branch. Give
guidance for typical bug fix process for existing releases.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In build environments which use gcc as the default compiler, use of the
clangd LSP server (for enhanced code editing and navigation etc.) with
libvirt requires some additional configuration. Detail this and link
from `hacking.rst`.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The "hacking" doc details where to find the code, but not how to compile
it - link to the instructions contained in `compiling.rst`.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are two guides to contributing: `hacking.rst` is focused on code
contributions, and `contributing.rst` is more general. Clarify scope of
`hacking.rst` and link to the general guide in its references.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Whilst the "docs" documentation map is linked in the navigation bar,
users may scroll down and lose sight of this, so also place at the
bottom of the "Quick Links" section.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than directly executing mdevctl from the udev event thread when
we determine that we need to re-query, schedule the mdevctl thread to
run. This also helps to coalesce multiple back-to-back updates into a
single one when there are multiple updates in a row or at startup when a
host has a very large number of mdevs.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Factor out a new scheduleMdevctlUpdate() function so that we can re-use
it from other places. Now that other events can make it necessary to
re-query mdevctl for mdev updates, this function will be useful for
coalescing multiple updates in quick succession into a single mdevctl
query.
Also rename a couple functions. The names weren't very descriptive of
their behavior. For example, the old scheduleMdevctlHandler() function
didn't actually schedule anything, it just started a thread. So rename
it to free up the 'schedule' name for the above refactored function.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Update the optional mdev attributes by running an mdevctl update on a
new created nodedev object representing an mdev.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143158
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
If a domain has NUMA configured, then all <memory/> devices
(except for 'virtio-pmem') need to have targetNode set. There are
two checks inside of qemuDomainDefValidateMemoryHotplugDevice()
for this: one inside of big switch() statement, which only checks
'dimm' and 'nvdimm' cases, and the other at the end of the
function that checks all models (except for 'virtio-pmem'). Let's
keep the latter and remove the former as the latter covers the
former too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
The libxl driver has basic support for VIR_MIGRATE_CHANGE_PROTECTION
by starting and stopping modify jobs in the begin/confirm and prepare/finish
phases of migration, but it doesn't advertise that support. This can result
in unterminated jobs because the migration logic skips phases of migration
when the VIR_MIGRATE_CHANGE_PROTECTION feature is absent. Ensure jobs are
terminated properly by advertising support for VIR_MIGRATE_CHANGE_PROTECTION.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For unknown reasons, the libxl driver attempts to resume a domain in the
confirm phase when a migration operation has been canceled. This has shown
to be problematic when simulating scenarios that result in a canceled
migration. In all scenarios, the domain was in a running state when entering
libxlDomainMigrationSrcConfirm, causing the call to libxl_domain_resume to
fail. Making matters worse, the domain state is changed to paused when in
fact it's running. And finally, libxlDomainMigrationSrcConfirm incorrectly
returns an error.
Remove this incorrect logic from libxlDomainMigrationSrcConfirm. On a
canceled migration it's sufficient to resume the lock process that was
paused in the perform phase.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Our CI started to enable udev backend on FreeBSD. And while there
is udev on FreeBSD some parts of our code are highly Linux
specific, e.g. translating SCSI device type to string (from an
integer obtained from the sysfs). Obviously, this doesn't work
anywhere else. This is the reason why we need to include
scsi/scsi.h header file (which actually comes from the Linux
kernel source tree but for some reason glibc started to
distribute it, followed by musl).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Asynchronous teardown can be specified if the QEMU binary supports it by
adding in the domain XML
<features>
...
<async-teardown enabled='yes|no'/>
...
</features>
By default this new feature is disabled.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU capability is looking in query-command-line-options response for
...
{
"parameters": [
{
"name": "async-teardown",
"type": "boolean"
}
],
"option": "run-with"
}
...
allow to use the QEMU option -run-with async-teardown=on|off
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Let us introduce the xml and reply files for QEMU 8.1.0 on s390x.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In newer QEMU libvirt combinations acpi support is no longer tolerated
and ignored. Therfore before upgrading the test capabilities to QEMU
8.1.0 replies removing the acpi feature from the domain XMLs.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Allow //disk/target@removable for scsi disk devices, since QEMU has support
the removable attribute for scsi-hd device from v0.14.0[1].
[1]: 419e691f8e: scsi-disk: Allow overriding SCSI INQUIRY removable bit
Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
openSUSE Leap 15.{4,5} are supported under libvirt's distro support
statement, but they only contain attr version 2.4.47.
Reverts: dffeef89ef
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Do for all other profiles what we already do for the
virt-aa-helper one. In this case we limit the feature to AppArmor
3.x, as it was never implemented for 2.x.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
For AppArmor 3.x we can use 'include if exists', which frees us
from having to create a dummy override. For AppArmor 2.x we keep
things as they are to avoid introducing regressions.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Implement the standard AppArmor 3.x abstraction extension
approach.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
The subprofile can only work by including the abstraction shipped
in the passt package, which we can't assume is present, and
'include if exists' doesn't work well on 2.x.
No distro that's stuck on AppArmor 2.x is likely to be shipping
passt anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Compared to profiles, we only need a single preprocessing step
here, as there is no variable substitution happening.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Perform an additional preprocessing step before the existing
variable substitution. This is the same approach that we already
use to customize systemd unit files based on whether the service
supports TCP connections.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We will soon need to base some decisions on whether AppArmor 3.x
or 2.x is present on the system.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
After v8.1.0-61-g030faee28d it is no longer necessary to make the
/proc/meminfo file nonseekable as our code that fills the file
with spoofed values can handle seeking just fine.
Previously, `free(1)` was okay with failed lseek(), but this was
ages ago and meanwhile the procps project moved to creating a
library and moved the file parsing code under an exported
function. In attempt to make the function callable multiple
times, it can lseek() multiple times and failure to do so is
fatal.
This reverts commit 7664955086
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/492
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix the syntax-check failures (which can be seen after
python3-flake8-import-order package is installed) with the help
of isort[1]:
289/316 libvirt:syntax-check / flake8 FAIL 5.24s exit status 2
[1]: https://pycqa.github.io/isort/
Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As it turns out, apparmor 2.x and 3.x behave differently or have differing
levels of support for local customizations of profiles and profile
abstractions. Additionally the apparmor 2.x tools do not cope well with
'include if exists'. Revert this commit until a more complete solution is
developed that works with old and new apparmor.
Reverts: 9b743ee190
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@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>
If VIR_ASYNC_JOB_NONE flag is present, job.current is equal
to NULL, which leads to SIGSEGV. Thus, this check should be
moved up.
Fixes: v8.0.0-427-gf304de0df6
Signed-off-by: Nikolai Barybin <nikolai.barybin@virtuozzo.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
