May 2020 - Devel - libvirt List Archives

[PATCH v1 0/8] Introducing TPM Proxy device support
by Daniel Henrique Barboza 13 May '20

13 May '20

Hello, This series implements a new device type for Libvirt called "TPM Proxy". This device acts as a proxy for TPM requisitions that the guest can make for an existing TPM Resource Manager in the host. The TPM Resource Manager multiplexes TPM access to multiple processes, allowing more than one process (guest) to use the host TPM at the same time. A guest using a TPM Proxy device does not have access to all possible TPM features. In that case the guest will need to assign a vTPM device (tpm-spapr for PPC64). There is no restrictions of using both a vTPM and a TPM Proxy device at the same time, but only one TPM Proxy is allowed per guest. At this moment, this device exists only for QEMU pSeries guests. A "model" field was added device to allow more models to be added when/if other architectures implements it. Daniel Henrique Barboza (8): docs: documentation and schema for the new TPM Proxy device qemu: Extend QEMU capabilities with 'spapr-tpm-proxy' conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY tests: add test for domain XML with TPM Proxy device model qemu: build command line for the TPM Proxy device tests/qemuxml2argvtest.c: add TPM Proxy command line test docs/news.xml: update for the new TPM Proxy device docs/formatdomain.html.in | 42 +++++ docs/news.xml | 14 ++ docs/schemas/domaincommon.rng | 18 ++ src/conf/domain_capabilities.c | 1 + src/conf/domain_conf.c | 160 ++++++++++++++++++ src/conf/domain_conf.h | 18 ++ src/conf/virconftypes.h | 3 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 16 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 21 +++ src/qemu/qemu_domain.c | 14 ++ src/qemu/qemu_domain_address.c | 2 + src/qemu/qemu_driver.c | 5 + src/qemu/qemu_hotplug.c | 3 + src/qemu/qemu_validate.c | 37 ++++ .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++ tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++ tests/qemuxml2argvtest.c | 4 + tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++ tests/qemuxml2xmltest.c | 4 + 24 files changed, 465 insertions(+) create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml -- 2.26.2

4 30

[PATCH] security: do not log password
by Zhang Bo 12 May '20

12 May '20

It's insecure to log password, nomatter the password is encrypted or not. And do not log it even in debug mode, in the consideration of resilience, surposing that the log mode has been modified by the attacker. Signed-off-by: Zhang Bo <oscar.zhangbo(a)huawei.com> --- src/libvirt-domain.c | 3 +-- src/qemu/qemu_monitor.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index a12809c2d5..e2a57c178b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -11340,8 +11340,7 @@ virDomainSetUserPassword(virDomainPtr dom, const char *password, unsigned int flags) { - VIR_DOMAIN_DEBUG(dom, "user=%s, password=%s, flags=0x%x", - NULLSTR(user), NULLSTR(password), flags); + VIR_DOMAIN_DEBUG(dom, "user=%s, flags=0x%x", NULLSTR(user), flags); virResetLastError(); diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 9c853ccb93..9bfaf53b65 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -2241,8 +2241,7 @@ qemuMonitorSetPassword(qemuMonitorPtr mon, if (!protocol) return -1; - VIR_DEBUG("protocol=%s, password=%p, action_if_connected=%s", - protocol, password, action_if_connected); + VIR_DEBUG("protocol=%s, action_if_connected=%s", protocol, action_if_connected); QEMU_CHECK_MONITOR(mon); -- 2.23.0.windows.1

2 1

[PATCH 0/5] qemu: Allow snapshots and blockcopy of read-only disks
by Peter Krempa 11 May '20

11 May '20

First one doesn't make much sense but oVirt used it before, so we should allow it now as well. Block copy makes sense and thus should be fixed either way. Last patch is for actually validating that it works. Peter Krempa (5): storage_file: create: Create new images with write permission bit qemuBlockStorageSourceCreateFormat: Force write access when formatting images qemu: snapshot: Allow snapshots of read-only disks when we can create them qemu: blockcopy: Allow copy of read-only disks with -blockdev HACK: qemu: caps: enable blockdev reopen src/qemu/qemu_block.c | 12 ++++++++++++ src/qemu/qemu_blockjob.c | 5 +++++ src/qemu/qemu_capabilities.c | 1 + src/qemu/qemu_driver.c | 11 ++++++++++- src/qemu/qemu_monitor_json.c | 2 +- src/storage/storage_file_fs.c | 6 +----- src/storage/storage_file_gluster.c | 6 +----- tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 + 23 files changed, 47 insertions(+), 12 deletions(-) -- 2.26.2

2 10

[libvirt-ci PATCH 00/12] Introduce a new global YAML config file for lcitool
by Erik Skultety 11 May '20

11 May '20

This series is trying to consolidate the number of config files we currently recognize under ~/.config/lcitool to a single global YAML config file. Thanks to this effort we can expose more seetings than we previously could which will come handy in terms of generating cloudinit images for OpenStack. Patches 1-4 patches are just a little extra - not heavily related to the series Patches 1-3 (ACKed) only cosmetical changes (like moving requirements.txt) Since RFC: - replaced TOML with YAML which simplified some aspects of the code, thanks Andrea - instead of hardcoding the default values, the config within the repo is used as a template and overriden with user-selected options Erik Skultety (12): requirements: Introduce a requirements.txt file lcitool: Decrease the indent when creating a tempdir for initrd injection lcitool: Prefer tempfile's native wrappers over low level primitives lcitool: Use a temporary JSON file to pass extra variables config: Introduce a new global config.yaml configuration file lcitool: Introduce methods to load and validate the YAML config lcitool: Update the config values with internal playbook settings lcitool: Drop the get_flavor() method lcitool: Drop the get_root_password_file() method lcitool: Drop the gitlab-related getter methods config: Move the virt-install settings from install.yml to the config guests: README: Document the existence and usage of config.toml guests/README.markdown | 18 +- guests/config.yaml | 40 +++++ guests/lcitool | 192 +++++++++------------- guests/playbooks/build/main.yml | 2 +- guests/playbooks/update/main.yml | 6 +- guests/playbooks/update/tasks/gitlab.yml | 4 +- guests/playbooks/update/tasks/kludges.yml | 2 +- guests/playbooks/update/tasks/users.yml | 42 ++--- guests/requirements.txt | 2 + 9 files changed, 159 insertions(+), 149 deletions(-) create mode 100644 guests/config.yaml create mode 100644 guests/requirements.txt -- 2.25.3

2 28

[libvirt-ci PATCH] lcitool: Catch exceptions earlier
by Andrea Bolognani 11 May '20

11 May '20

Right now we catch and report properly only those exceptions that are raised by the Application.run() method: basically, we work under the assumption that nothing before that point can possibly fail. That's of course unrealistic: even now, creating an Inventory or Projects object can raise an exception, in which case we simply display a stack trace instead of a reasonable error message. This commit introduces a CommandLine class which takes over command line handling from the Application class, and moves all exception handling to the main() method so that, short of something going horribly wrong while parsing the command line, we will always manage to hide stack traces from the user. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/lcitool | 56 ++++++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 24 deletions(-) diff --git a/guests/lcitool b/guests/lcitool index ab3b95f..ff58829 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -390,15 +390,9 @@ class Projects: return self._packages[project] -class Application: +class CommandLine: def __init__(self): - self._config = Config() - self._inventory = Inventory() - self._projects = Projects() - - self._native_arch = Util.get_native_arch() - self._parser = argparse.ArgumentParser( conflict_handler="resolve", description="libvirt CI guest management tool", @@ -444,14 +438,14 @@ class Application: installparser = subparsers.add_parser( "install", help="perform unattended host installation") - installparser.set_defaults(func=self._action_install) + installparser.set_defaults(action="install") add_hosts_arg(installparser) add_wait_arg(installparser) updateparser = subparsers.add_parser( "update", help="prepare hosts and keep them updated") - updateparser.set_defaults(func=self._action_update) + updateparser.set_defaults(action="update") add_hosts_arg(updateparser) add_projects_arg(updateparser) @@ -459,7 +453,7 @@ class Application: buildparser = subparsers.add_parser( "build", help="build projects on hosts") - buildparser.set_defaults(func=self._action_build) + buildparser.set_defaults(action="build") add_hosts_arg(buildparser) add_projects_arg(buildparser) @@ -467,20 +461,33 @@ class Application: hostsparser = subparsers.add_parser( "hosts", help="list all known hosts") - hostsparser.set_defaults(func=self._action_hosts) + hostsparser.set_defaults(action="hosts") projectsparser = subparsers.add_parser( "projects", help="list all known projects") - projectsparser.set_defaults(func=self._action_projects) + projectsparser.set_defaults(action="projects") dockerfileparser = subparsers.add_parser( "dockerfile", help="generate Dockerfile (doesn't access the host)") - dockerfileparser.set_defaults(func=self._action_dockerfile) + dockerfileparser.set_defaults(action="dockerfile") add_hosts_arg(dockerfileparser) add_projects_arg(dockerfileparser) add_cross_arch_arg(dockerfileparser) + def parse(self): + return self._parser.parse_args() + + +class Application: + + def __init__(self): + self._config = Config() + self._inventory = Inventory() + self._projects = Projects() + + self._native_arch = Util.get_native_arch() + def _execute_playbook(self, playbook, hosts, projects, git_revision): base = Util.get_base() @@ -1011,17 +1018,18 @@ class Application: varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch) self._dockerfile_format(facts, cross_arch, varmap) - def run(self): - args = self._parser.parse_args() - if args.debug: - args.func(args) - else: - try: - args.func(args) - except Exception as err: - sys.stderr.write("{}: {}\n".format(sys.argv[0], err)) - sys.exit(1) + def run(self, args): + getattr(self, "_action_" + args.action)(args) if __name__ == "__main__": - Application().run() + args = CommandLine().parse() + + if args.debug: + Application().run(args) + else: + try: + Application().run(args) + except Exception as err: + sys.stderr.write("{}: {}\n".format(sys.argv[0], err)) + sys.exit(1) -- 2.25.4

2 2

[libvirt PATCH v2 0/3] docs: Some reStructuredText tweaks
by Andrea Bolognani 11 May '20

11 May '20

Changes from [v1]: * convert simple tables to definition lists; * drop glib-adoption.rst entirely instead of tweaking it. [v1] https://www.redhat.com/archives/libvir-list/2020-May/msg00292.html Andrea Bolognani (3): docs: Drop glib-adoption.rst docs: Use definition list instead of table in coding style docs: Document list-tables as recommended docs/coding-style.rst | 47 ++++++++++++--------- docs/glib-adoption.rst | 96 ------------------------------------------ docs/hacking.rst | 1 - docs/styleguide.rst | 20 +++++++++ 4 files changed, 46 insertions(+), 118 deletions(-) delete mode 100644 docs/glib-adoption.rst -- 2.25.4

3 7

[PATCH] virDevMapperGetTargetsImpl: quit early if device is not a devmapper target
by Michal Privoznik 11 May '20

11 May '20

As suggested in the linked bug, libvirt should firstly check whether the major number of the device is device mapper major. Because if it isn't subsequent DM_DEVICE_DEPS task may not only fail, but also yield different results. In the bugzilla this is demonstrated by creating a devmapper target named 'loop0' and then creating loop target /dev/loop0. When the latter is then passed to a domain, our virDevMapperGetTargetsImpl() function blindly asks devmapper to provide target dependencies for /dev/loop0 and because of the way devmapper APIs work, it will 'sanitize' the input by using the last component only which is 'loop0' and thus return different results than expected. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1823976 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virdevmapper.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/util/virdevmapper.c b/src/util/virdevmapper.c index feb5982315..ee026d502e 100644 --- a/src/util/virdevmapper.c +++ b/src/util/virdevmapper.c @@ -64,6 +64,7 @@ virDevMapperGetTargetsImpl(const char *path, char ***devPaths_ret, unsigned int ttl) { + struct stat sb; struct dm_task *dmt = NULL; struct dm_deps *deps; struct dm_info info; @@ -82,6 +83,15 @@ virDevMapperGetTargetsImpl(const char *path, return ret; } + if (stat(path, &sb) < 0) { + if (errno == ENOENT) + ret = 0; + return ret; + } + + if (!dm_is_dm_major(major(sb.st_dev))) + return 0; + if (!(dmt = dm_task_create(DM_DEVICE_DEPS))) { if (errno == ENOENT || errno == ENODEV) { /* It's okay. Kernel is probably built without -- 2.26.2

2 1

[libvirt-ci PATCH] lcitool: Set make parallelism dynamically
by Andrea Bolognani 11 May '20

11 May '20

We're about to make some changes to lcitool that would make it more annoying to get access to the number of install-time vCPUs from 'lcitool update', so let's use getconf instead. As a side effect, this also copes better with the situation where the builder was installed with a certain number of vCPUs but the amount has since been modified. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/playbooks/update/templates/bashrc.j2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guests/playbooks/update/templates/bashrc.j2 b/guests/playbooks/update/templates/bashrc.j2 index 8775864..05a86a1 100644 --- a/guests/playbooks/update/templates/bashrc.j2 +++ b/guests/playbooks/update/templates/bashrc.j2 @@ -4,7 +4,7 @@ export MAKE="{{ paths.make }}" export NINJA="{{ paths.ninja }}" export PYTHON="{{ paths.python }}" -export MAKEFLAGS="-j{{ install_vcpus|int + 1 }}" +export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)" export CCACHE_MAXSIZE="2G" export VIRT_PREFIX="$HOME/build/libvirt" -- 2.25.4

2 4

[libvirt PATCH v2] docs: introduce a page showing a overall CI dashboard
by Daniel P. Berrangé 11 May '20

11 May '20

With the move to GitLab CI one of the things we miss from Jenkins is a single page dashboard showing CI status across all projects. This is a very simple replacement that uses badges for CI pipeline status. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/ci.rst | 230 ++++++++++++++++++++++++++++++++++++++++++++++ docs/docs.html.in | 3 + docs/libvirt.css | 5 + 3 files changed, 238 insertions(+) create mode 100644 docs/ci.rst diff --git a/docs/ci.rst b/docs/ci.rst new file mode 100644 index 0000000000..fe59b98923 --- /dev/null +++ b/docs/ci.rst @@ -0,0 +1,230 @@ +============================== +Libvirt Continuous Integration +============================== + +.. contents:: + +The libvirt project primarily uses GitLab CI for automated testing of Linux +builds, and cross-compiled Windows builds. `Travis <https://travis-ci.org/libvirt/libvirt>`_ +is used for validating macOS builds, and `Jenkins <https://ci.centos.org/view/libvirt>`_ +is temporarily used for validating FreeBSD builds. + +GitLab CI Dashboard +=================== + +The dashboard below shows the current status of the GitLab CI jobs for each +repository: + +Core project +------------ + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + + * - libvirt + - .. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt/pipelines + :alt: libvirt pipeline status + + +Language bindings +----------------- + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + + * - libvirt-csharp + - .. image:: https://gitlab.com/libvirt/libvirt-csharp/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-csharp/pipelines + :alt: libvirt-csharp pipeline status + + * - libvirt-go + - .. image:: https://gitlab.com/libvirt/libvirt-go/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-go/pipelines + :alt: libvirt-go pipeline status + + * - libvirt-java + - .. image:: https://gitlab.com/libvirt/libvirt-java/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-java/pipelines + :alt: libvirt-java pipeline status + + * - libvirt-ocaml + - .. image:: https://gitlab.com/libvirt/libvirt-ocaml/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-ocaml/pipelines + :alt: libvirt-ocaml pipeline status + + * - libvirt-perl + - .. image:: https://gitlab.com/libvirt/libvirt-perl/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-perl/pipelines + :alt: libvirt-perl pipeline status + + * - libvirt-php + - .. image:: https://gitlab.com/libvirt/libvirt-php/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-php/pipelines + :alt: libvirt-php pipeline status + + * - libvirt-python + - .. image:: https://gitlab.com/libvirt/libvirt-python/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-python/pipelines + :alt: libvirt-python pipeline status + + * - libvirt-rust + - .. image:: https://gitlab.com/libvirt/libvirt-rust/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-rust/pipelines + :alt: libvirt-rust pipeline status + + * - ruby-libvirt + - .. image:: https://gitlab.com/libvirt/ruby-libvirt/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/ruby-libvirt/pipelines + :alt: ruby-libvirt pipeline status + + +Object mappings +--------------- + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + + * - libvirt-cim + - .. image:: https://gitlab.com/libvirt/libvirt-cim/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-cim/pipelines + :alt: libvirt-cim pipeline status + + * - libvirt-dbus + - .. image:: https://gitlab.com/libvirt/libvirt-dbus/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-dbus/pipelines + :alt: libvirt-dbus pipeline status + + * - libvirt-glib + - .. image:: https://gitlab.com/libvirt/libvirt-glib/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-glib/pipelines + :alt: libvirt-glib pipeline status + + * - libvirt-go-xml + - .. image:: https://gitlab.com/libvirt/libvirt-go-xml/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-go-xml/pipelines + :alt: libvirt-go-xml pipeline status + + * - libvirt-snmp + - .. image:: https://gitlab.com/libvirt/libvirt-snmp/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-snmp/pipelines + :alt: libvirt-snmp pipeline status + + +Testing +------- + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + + * - libvirt-ci + - .. image:: https://gitlab.com/libvirt/libvirt-ci/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-ci/pipelines + :alt: libvirt-ci pipeline status + + * - libvirt-dockerfiles + - .. image:: https://gitlab.com/libvirt/libvirt-dockerfiles/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-dockerfiles/pipelines + :alt: libvirt-dockerfiles pipeline status + + * - libvirt-test-API + - .. image:: https://gitlab.com/libvirt/libvirt-test-API/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-test-API/pipelines + :alt: libvirt-test-API pipeline status + + * - libvirt-tck + - .. image:: https://gitlab.com/libvirt/libvirt-tck/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-tck/pipelines + :alt: libvirt-tck pipeline status + + +Documentation / websites +------------------------ + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + * - libvirt-publican + - .. image:: https://gitlab.com/libvirt/libvirt-publican/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-publican/pipelines + :alt: libvirt-publican pipeline status + + * - libvirt-appdev-guide-python + - .. image:: https://gitlab.com/libvirt/libvirt-appdev-guide-python/badges/master/pipeli… + :target: https://gitlab.com/libvirt/libvirt-appdev-guide-python/pipelines + :alt: libvirt-appdev-guide-python pipeline status + + * - libvirt-wiki + - .. image:: https://gitlab.com/libvirt/libvirt-wiki/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-wiki/pipelines + :alt: libvirt-wiki pipeline status + + * - virttools-planet + - .. image:: https://gitlab.com/libvirt/virttools-planet/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/virttools-planet/pipelines + :alt: virttools-planet pipeline status + + * - virttools-web + - .. image:: https://gitlab.com/libvirt/virttools-web/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/virttools-web/pipelines + :alt: virttools-web pipeline status + + +Miscellaneous +------------- + +.. list-table:: + :widths: 80 20 + :header-rows: 1 + + * - Project + - Pipeline + + * - libvirt-console-proxy + - .. image:: https://gitlab.com/libvirt/libvirt-console-proxy/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-console-proxy/pipelines + :alt: libvirt-console-proxy pipeline status + + * - libvirt-designer + - .. image:: https://gitlab.com/libvirt/libvirt-designer/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-designer/pipelines + :alt: libvirt-designer pipeline status + + * - libvirt-devaddr + - .. image:: https://gitlab.com/libvirt/libvirt-devaddr/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-devaddr/pipelines + :alt: libvirt-devaddr pipeline status + + * - libvirt-sandbox + - .. image:: https://gitlab.com/libvirt/libvirt-sandbox/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-sandbox/pipelines + :alt: libvirt-sandbox pipeline status + + * - libvirt-sandbox-image + - .. image:: https://gitlab.com/libvirt/libvirt-sandbox-image/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-sandbox-image/pipelines + :alt: libvirt-sandbox-image pipeline status + + * - libvirt-security-notice + - .. image:: https://gitlab.com/libvirt/libvirt-security-notice/badges/master/pipeline.s… + :target: https://gitlab.com/libvirt/libvirt-security-notice/pipelines + :alt: libvirt-security-notice pipeline status diff --git a/docs/docs.html.in b/docs/docs.html.in index 6bdf0c32b8..f1d44fadc0 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -142,6 +142,9 @@ <dt><a href="strategy.html">Project strategy</a></dt> <dd>Sets a vision for future direction & technical choices</dd> + <dt><a href="ci.html">CI Testing</a></dt> + <dd>Details of the Continuous Integration testing strategy</dd> + <dt><a href="bugs.html">Bug reports</a></dt> <dd>How and where to report bugs and request features</dd> diff --git a/docs/libvirt.css b/docs/libvirt.css index 94d0b9058c..a2c9778e03 100644 --- a/docs/libvirt.css +++ b/docs/libvirt.css @@ -592,3 +592,8 @@ td.gitmirror { td.gitmirror a { color: inherit; } + +th p, td p { + margin-top: 0px; + margin-bottom: 0px; +} -- 2.26.2

2 3

[PATCH] qemuDomainCleanupRun: Actually run cleanup callbacks in reverse order
by Michal Privoznik 11 May '20

11 May '20

We have a framework to register cleanup callbacks that are run when a domain is shut down. The idea is to run callbacks in reverse order than they were registered. However, looking at the code this is not the case. Fortunately, this framework is used to register a single callback and a single callback only - qemuMigrationDstPrepareCleanup() - therefore there was no problem just yet. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 9c629c31a3..7c71b797bc 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8032,18 +8032,14 @@ qemuDomainCleanupRun(virQEMUDriverPtr driver, virDomainObjPtr vm) { qemuDomainObjPrivatePtr priv = vm->privateData; - size_t i; VIR_DEBUG("driver=%p, vm=%s", driver, vm->def->name); /* run cleanup callbacks in reverse order */ - for (i = 0; i < priv->ncleanupCallbacks; i++) { - if (priv->cleanupCallbacks[priv->ncleanupCallbacks - (i + 1)]) - priv->cleanupCallbacks[i](driver, vm); - } + while (priv->ncleanupCallbacks) + priv->cleanupCallbacks[--priv->ncleanupCallbacks](driver, vm); VIR_FREE(priv->cleanupCallbacks); - priv->ncleanupCallbacks = 0; priv->ncleanupCallbacks_max = 0; } -- 2.26.2

2 1