September 2019 - Devel - libvirt List Archives

[libvirt] [PATCH] docs: attempt to document the general libvirt dev strategy
by Daniel P. Berrangé 23 Sep '19

23 Sep '19

There are various ideas / plans floating around for future libvirt work, some of which is actively in progress. Historically we've never captured this kind of information anywhere, except in mailing list discussions. In particular guidelines in hacking.html.in don't appear until a policy is actively applied. This patch attempts to fill the documentation gap, by creating a new "strategy" page which outlines the general vision for some notable future changes. The key thing to note is that none of the stuff on this page is guaranteed, plans may change as new information arises. IOW this is a "best guess" as to the desired future. This doc has focused on three areas, related to the topic of language usage / consolidation - Use of non-C languages for the library, daemons or helper tools - Replacement of autotools with meson - Use of RST and Sphinx for documentation (website + man pages) Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/docs.html.in | 3 + docs/strategy.html.in | 143 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 docs/strategy.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index c1741c89b4..6cf09f51bc 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -128,6 +128,9 @@ <dt><a href="hacking.html">Contributor guidelines</a></dt> <dd>General hacking guidelines for contributors</dd> + <dt><a href="strategy.html">Project strategy</a></dt> + <dd>Sets a vision for future direction & technical choices</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/strategy.html.in b/docs/strategy.html.in new file mode 100644 index 0000000000..41bbebb8f9 --- /dev/null +++ b/docs/strategy.html.in @@ -0,0 +1,143 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Libvirt Project Strategy</h1> + + <p> + This document attempts to outline the libvirt project strategy for + the near future. Think of this is a high level vision or todo list + setting the direction for the project & its developers to take + </p> + + <h2>Language consolidation</h2> + + <p> + At time of writing libvirt uses the following languages + </p> + + <dl> + <dt>C</dt> + <dd>The core libvirt library, daemons, and helper tools are all written + in the C language.</dd> + <dt>Python</dt> + <dd>Various supporting build/test scripts are written in Python, with + compatibility for Python 2 and 3.</dd> + <dt>Perl</dt> + <dd>Various supporting build/test scripts are written in Python. It is + also used for many syntax-check inline rules</dd> + <dt>Shell</dt> + <dd>The autoconf configure script, is essentially shell script. Shell + is also used for some simple build/test scripts. At runtime libvirt + avoids shell except when using SSH tunnels to a remote host</dd> + <dt>XSLT</dt> + <dd>The website documentation is subsituted into templates using XSLT + scripts. The API documentation is also autogenerated from an XML + description using XSLT</dd> + <dt>HTML</dt> + <dd>The website documentation is all written in plain HTML. Some HTML + is also auto-generated for API documentation</dd> + <dt>M4</dt> + <dd>The autoconf configure script uses a large number of M4 macros to + generate its content</dd> + <dt>make</dt> + <dd>The core build system uses the traditional GNU make recipes</dd> + <dt>automake</dt> + <dd>The make recipes make use of automake's make language extensions + which are then turned into regular make rules</dd> + <dt>awk/sed</dt> + <dd>A number of the syntax-check inline rules involve use of awk/sed + scripts</dd> + <dt>POD</dt> + <dd>The command line manual pages are typically written in Perl's POD + format, and converted to troff</dt> + </dl> + + <p> + The wide range of languages used present a knowledge burden for + developers involved in libvirt, especially when there are multiple + languages all used in the same problem spaces. This is most notable + in the build system which uses a combination of shell, m4, make, + automake, awk, sed, perl and python, with debugging requiring + understanding of the interactions between many languages. The + relative popularity of the languages has implications for how easily + the project can attract new contributors, and the quality of the code + they'll be able to submit. This is most notable when comparing Perl + to Python, as since the start of the libvirt project, the popularity + and knowledge of Perl has declined, while Python has risen. + </p> + <p> + The C language has served libvirt well over the years, but its age shows + giving rise to limitations which negatively impact the project in terms + of code quality, reliability, and efficiency of development. Most notably + its lack of memory safety means that many code bugs become trivially + exploitable security flaws or denial of service. The lack of a high + level portable runtime, resulting in alot of effort being spent to + ensure cross platform portability. The modern languages Rust and Go + provide viable options for low level systems programming, in a way that + was not practical with other common languages such as Python and Java. + There is thus a desire to make use of either Rust or Go, or more likely + a combination of both, to incrementally replace existing use of C, and + also for greenfield development. + </p> + <p> + With this in mind the libvirt project has set a vision for language + usage in the future + </p> + + <dl> + <dt>C</dt> + <dd>The core libvirt library, daemons, and helper tools are all written + in the C language.</dd> + <dt>Rust</dt> + <dd>Parts of the core libvirt library / daemon are to be able to leverage + Rust to replace C. (TBD vs Go)</dd> + <dt>Go</dt> + <dd>Parts of the core libvirt library / daemon are to be able to leverage + Rust to replace C. (TBD vs Rust). Helper tools are able to be written + in Go.</dd> + <dt>Meson</dt> + <dd>The core build system is to be written in meson.</dd> + <dt>Python</dt> + <dd>Various supporting build/test scripts are written in Python 3 + compatible mode only.</dd> + <dt>RST</dt> + <dd>The website and command man pages are to be written in RST, using + Sphinx as the engine to convert to end user formats like HTML, troff, + etc</dd> + </dl> + + <p> + Some notable points from the above. Whether the core library / daemons + will use Rust or Go internally is still to be decided based on more + detailed evaluation of their pros and cons, to identify the best fit, + as the need to link & embed this functionality in other processes has + complex interactions both at a technical and non-technical level. For + standalone helper tools, Go is a good fit for rapid development as + there are no concerns around interactions with other in-process code + from 3rd parties. + </p> + + <p> + The meson build system is written in Python, at time of writing, + requiring version 3.4 or later. This directly informs the choice to use + Python 3.4 as the language for all supporting build scripts, re-inforcing + the other benefits of Python, over Perl, Shell, M4, automake, etc. + </p> + + <p> + Using the RST format for documentation allows for the use of XSLT to be + eliminated from the build process. RST and the Sphinx toolkit are widely + used, as seen by the huge repository of content on + https://readthedocs.org/. The ability embed raw HTML in the RST docs will + greatly facilitate its adoption, avoiding the need for a big bang + conversion of existing content. Given the desire to eliminate Perl + usage, replacing the use of POD documentation for manual pages is an + obvious followup task. RST is the obvious choice to given alignment + with the website, allowing the man pages to be easily published online + with other docs. It is further anticipated that the current API docs + generator which uses XSLT to convert the XML API description would be + converted to something which generates RST using Python instead of XSL. + </p> + </body> +</html> -- 2.21.0

4 5

[libvirt] [PATCH] docs: kbase: Add a section explaining how to verify SEV from the guest
by Erik Skultety 23 Sep '19

23 Sep '19

Commit 50dfabbb59 forgot to add this important bit on how to check that all the changes to the XML actually worked. --- docs/kbase/launch_security_sev.html.in | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/kbase/launch_security_sev.html.in b/docs/kbase/launch_security_sev.html.in index 923bb52b25..4b8e06ccc1 100644 --- a/docs/kbase/launch_security_sev.html.in +++ b/docs/kbase/launch_security_sev.html.in @@ -349,6 +349,18 @@ EOF</pre> ... </domain></pre> + <h2><a id="Guest">Checking SEV from within the guest</a></h2> + <p> + After making the necessary adjustments discussed in + <a href="#Configuration">Configuration</a>, the VM should now boot + successfully with SEV enabled. You can then verify that the guest + enabled with SEV by running: + </p> + + <pre> +# dmesg | grep -i sev +AMD Secure Encrypted Virtualization (SEV) active</pre> + <h2><a id="Limitations">Limitations</a></h2> <p> Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi -- 2.20.1

3 5

[libvirt] [PATCH v4 00/20] Add vhost-user-gpu support
by marcandre.lureau＠redhat.com 23 Sep '19

23 Sep '19

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This series adds support for running virtio GPUs in seperate processes, thanks to vhost-user backend. The QEMU support landed for 4.1. There are several benefits of running the GPU/virgl in an external process, since Mesa is rather heavy on the qemu main loop, and may block for a while, or crash. The external GPU process is started with one end of a socket pair, the other end is given to a QEMU chardev attached to a device. The external process is also added to the cgroup to limit resources usage. vhost-user is a generic mechanism that allows implementing virtio device dataplane handling in a separate userspace process. vhost-user-gpu here notably moves the virgl 3d handling out of the main qemu process. The external process will be /usr/libexec/vhost-user-gpu, which comes from qemu.git contrib/vhost-user-gpu code, first released in qemu-4.1. Part of this series deals with discovering the location on disk of the vhost-user-gpu binary, and what capabilities it provides. This uses a similar mechanism to firmware.json, described in qemu docs/interop/vhost-user.json https://github.com/qemu/qemu/blob/master/docs/interop/vhost-user.json qemu 4.1 ships a 50-qemu-gpu.json to match. I believe virtio-fs will use a similar mechanism when it lands in upstream qemu, as virtiofsd is a separate process that communicates with qemu over vhost-user. For a bit more background on vhost-user-gpu process handling and the json interop motivation, here's some of the qemu discussion: https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg02610.html https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00807.html For this series, the XML to enable this is: <video model='virtio'> <driver name='vhostuser'/> <acceleration accel3d='yes' rendernode='/path/to/rendernode'/> </video> rendernode is optional qemu_vhost_user.c handles vhost-user.json qemu_vhost_user_gpu.c handles the process management for vhost-user-gpu v4: - rebased - simplify vhost-user-gpu pidfile checking - fix check/syntax-check v3: - rename qemu_configs -> qemu_interop_config - replace <model .. vhostuser='yes'/> with <driver name='vhostuser'/> - move vhost_user_binary to virDomainVideoDriverDef - some VIR_AUTO usage improvements - introduce qemuDomainVideoPrivate to store vhost-user fd - improved selection of -device model - use DO_TEST_CAPS_LATEST - allocate a rendernode with virHostGetDRMRenderNode() - but no clear idea how to have a test - add a patch to ignore EPERM in virDirOpenIfExists() - better domain checks/validate - added Ján r-b - no s-o-b from Cole, per request and commits taken from his git branch - rebase, indentation/style fixes, update doc, version.. v2: - rebase to master - if test file build by dropping LDADDS usage - syntax-check issues: * use #pragma once * if () bracket issues * jump label indent issues * error message %s usage * size_t for loops Marc-André Lureau (20): qemu: generalize qemuFetchConfigs util: ignore EACCESS in virDirOpenIfExists conf: format/parse/rng/docs for video <driver name='qemu|vhostuser'/> domain: add rendernode attribute on <accel> qemu-cgroup: allow accel rendernode access qemu: add vhost-user-gpu capabilities checks qemu: check that qemu is vhost-user-vga capable qemu: validate virtio-gpu with vhost-user qemu: restrict 'virgl=' option to non-vhostuser video type qemu: add vhost-user helpers qemu: add qemuSecurityStartVhostUserGPU helper conf: add privateData to virDomainVideoDef qemu: add qemuDomainVideoPrivate qemu: add vhost-user-gpu helper unit tests: mock execv/execve tests: wrap vhost-user paths in qemuxml2argvtest qemu: prepare domain for vhost-user GPU qemu: start/stop the vhost-user-gpu external device qemu: build vhost-user GPU devices tests: add vhost-user-gpu xml2argv tests docs/formatdomain.html.in | 18 +- docs/schemas/domaincommon.rng | 13 + src/conf/domain_conf.c | 87 +++- src/conf/domain_conf.h | 21 +- src/qemu/Makefile.inc.am | 6 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 24 + src/qemu/qemu_command.c | 65 ++- src/qemu/qemu_domain.c | 52 ++- src/qemu/qemu_domain.h | 12 + src/qemu/qemu_extdevice.c | 74 ++- src/qemu/qemu_extdevice.h | 5 + src/qemu/qemu_firmware.c | 144 +----- src/qemu/qemu_interop_config.c | 183 ++++++++ src/qemu/qemu_interop_config.h | 25 ++ src/qemu/qemu_process.c | 61 ++- src/qemu/qemu_security.c | 40 ++ src/qemu/qemu_security.h | 6 + src/qemu/qemu_vhost_user.c | 422 ++++++++++++++++++ src/qemu/qemu_vhost_user.h | 48 ++ src/qemu/qemu_vhost_user_gpu.c | 276 ++++++++++++ src/qemu/qemu_vhost_user_gpu.h | 49 ++ src/util/virfile.c | 13 +- tests/Makefile.am | 9 + .../caps_4.1.0.x86_64.xml | 2 + .../etc/qemu/vhost-user/40-gpu.json | 1 + .../etc/qemu/vhost-user/50-gpu.json | 0 .../qemu/vhost-user/test-vhost-user-gpu | 11 + .../usr/share/qemu/vhost-user/30-gpu.json | 1 + .../usr/share/qemu/vhost-user/50-gpu.json | 8 + .../usr/share/qemu/vhost-user/60-gpu.json | 1 + tests/qemuvhostusertest.c | 132 ++++++ ...host-user-gpu-secondary.x86_64-latest.args | 43 ++ .../vhost-user-gpu-secondary.xml | 46 ++ .../vhost-user-vga.x86_64-latest.args | 40 ++ tests/qemuxml2argvdata/vhost-user-vga.xml | 42 ++ tests/qemuxml2argvdata/virtio-options.args | 5 +- tests/qemuxml2argvdata/virtio-options.xml | 4 +- tests/qemuxml2argvtest.c | 16 +- tests/virfilewrapper.c | 22 + 41 files changed, 1827 insertions(+), 210 deletions(-) create mode 100644 src/qemu/qemu_interop_config.c create mode 100644 src/qemu/qemu_interop_config.h create mode 100644 src/qemu/qemu_vhost_user.c create mode 100644 src/qemu/qemu_vhost_user.h create mode 100644 src/qemu/qemu_vhost_user_gpu.c create mode 100644 src/qemu/qemu_vhost_user_gpu.h create mode 120000 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json create mode 100644 tests/qemuvhostuserdata/etc/qemu/vhost-user/50-gpu.json create mode 100755 tests/qemuvhostuserdata/usr/libexec/qemu/vhost-user/test-vhost-user-gpu create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/30-gpu.json create mode 100644 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/50-gpu.json create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/60-gpu.json create mode 100644 tests/qemuvhostusertest.c create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.xml -- 2.23.0

4 37

[libvirt] [PATCH] qemu: fix operation job association when qemuCaps is NULL.
by jcfaracco＠gmail.com 23 Sep '19

23 Sep '19

From: Julio Faracco <jcfaracco(a)gmail.com> Function qemuMigrationEatCookie() calls qemuMigrationCookieXMLParseStr(), when qemuCaps is not set, function assumes priv as a NULL pointer. At the end, function tries to set job info operation to the same current job. But, if priv is NULL due to missing qemuCaps, code returns a Null Pointer Exception. This commit adds an extra check to verify it. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/qemu/qemu_migration_cookie.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration_cookie.c b/src/qemu/qemu_migration_cookie.c index 25d3fecd74..945b640e2c 100644 --- a/src/qemu/qemu_migration_cookie.c +++ b/src/qemu/qemu_migration_cookie.c @@ -1538,7 +1538,8 @@ qemuMigrationEatCookie(virQEMUDriverPtr driver, } } - if (flags & QEMU_MIGRATION_COOKIE_STATS && mig->jobInfo) + if (flags & QEMU_MIGRATION_COOKIE_STATS && mig->jobInfo && + priv && priv->job.current) mig->jobInfo->operation = priv->job.current->operation; return mig; -- 2.20.1

2 1

[libvirt] [PATCH 0/4] Colourize configure output
by Michal Privoznik 23 Sep '19

23 Sep '19

An example how configure looks like with these changes applied: https://travis-ci.org/zippy2/libvirt/jobs/582549099#L4247 Michal Prívozník (4): configure: Prefer LIBVIRT_RESULT over AC_MSG_NOTICE virt-result.m4: Align string more generously configure: Colorize output virt-result.m4: Colourize summary printings configure.ac | 8 ++--- m4/virt-chrdev-lock-files.m4 | 2 +- m4/virt-colours.m4 | 62 ++++++++++++++++++++++++++++++++++++ m4/virt-debug.m4 | 2 +- m4/virt-default-editor.m4 | 2 +- m4/virt-dtrace.m4 | 2 +- m4/virt-host-validate.m4 | 2 +- m4/virt-init-script.m4 | 2 +- m4/virt-loader-nvram.m4 | 2 +- m4/virt-login-shell.m4 | 2 +- m4/virt-numad.m4 | 2 +- m4/virt-result.m4 | 21 ++++++++++-- 12 files changed, 93 insertions(+), 16 deletions(-) create mode 100644 m4/virt-colours.m4 -- 2.21.0

4 17

[libvirt] [PATCH 1/2] libvirt-rust: Fix bugs in Stream::recv
by Linus Färnstrand 23 Sep '19

23 Sep '19

* pass same size to virStreamRecv as the buffer has allocated * Handle -2 error case * Fix FFI declaration to take size_t instead of c_uint * Allow user to pass in buffer. To allow user to decide where to allocate it. And to be able to re-use the same buffer * Don't try to treat binary data as a string Signed-off-by: Linus Färnstrand <faern(a)faern.net> --- src/stream.rs | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/src/stream.rs b/src/stream.rs index 8333ee5..af6c8ec 100644 --- a/src/stream.rs +++ b/src/stream.rs @@ -18,6 +18,7 @@ extern crate libc; +use std::convert::TryFrom; use std::str; use error::Error; @@ -37,7 +38,7 @@ extern "C" { -> libc::c_int; fn virStreamRecv(c: sys::virStreamPtr, data: *mut libc::c_char, - nbytes: libc::c_uint) + nbytes: libc::size_t) -> libc::c_int; fn virStreamFree(c: sys::virStreamPtr) -> libc::c_int; fn virStreamAbort(c: sys::virStreamPtr) -> libc::c_int; @@ -116,14 +117,14 @@ impl Stream { } } - pub fn recv(&self, size: u32) -> Result<String, Error> { - unsafe { - let mut data: [libc::c_char; 2048] = ['\0' as i8; 2048]; - let ret = virStreamRecv(self.as_ptr(), data.as_mut_ptr(), size as libc::c_uint); - if ret == -1 { - return Err(Error::new()); - } - return Ok(c_chars_to_string!(data.as_ptr())); - } + pub fn recv(&self, buf: &mut [u8]) -> Result<usize, Error> { + let ret = unsafe { + virStreamRecv( + self.as_ptr(), + buf.as_mut_ptr() as *mut libc::c_char, + buf.len(), + ) + }; + usize::try_from(ret).map_err(|_| Error::new()) } } -- 2.21.0

2 3

[libvirt] [PATCH 0/3] use VIR_AUTOFREE() with strings in qemu_hotplug.c
by Daniel Henrique Barboza 23 Sep '19

23 Sep '19

Similar work to [1], but this time someone already changed the virQEMUDriverConfigPtr to use VIR_AUTOUNREF() in this file, which is less work pending to do, which is good. This change in particular will royally mess up with my rebases, but it's for a good cause. [1] https://www.redhat.com/archives/libvir-list/2019-September/msg00719.html Daniel Henrique Barboza (3): qemu_hotplug.c: use VIR_AUTOFREE() in strings 1/3 qemu_hotplug.c: use VIR_AUTOFREE() in strings 2/3 qemu_hotplug.c: use VIR_AUTOFREE() in strings 3/3 src/qemu/qemu_hotplug.c | 286 +++++++++++++--------------------------- 1 file changed, 95 insertions(+), 191 deletions(-) -- 2.21.0

2 6

[libvirt] [PATCH v2 0/2] a few cleanups in qemu_domain_address.c
by Daniel Henrique Barboza 23 Sep '19

23 Sep '19

Second round of these cleanups after the reviews from Eric. changes from v1: - fixed the commit message of patch 1 - ditched the virPCIAddressSet() approach - use direct assignment instead v1: https://www.redhat.com/archives/libvir-list/2019-September/msg00823.html Daniel Henrique Barboza (2): qemu_domain_address.c: use VIR_AUTOFREE() in strings qemu_domain_address: use virPCIDeviceAddressEqual() in conditionals src/qemu/qemu_domain_address.c | 125 +++++++++++++++------------------ 1 file changed, 55 insertions(+), 70 deletions(-) -- 2.21.0

2 4

[libvirt] [PATCH] conf: reattach interface taps to correct bridge on restart
by Laine Stump 20 Sep '19

20 Sep '19

When the bridge re-attach handling was moved out of the network driver and into the hypervisor driver (commit b806a60e) as a part of the refactor to split the network driver into a separate daemon, the check was accidentally changed to only check for type='bridge'. The check for type in this case needs to check for type='network' as well. (at the time we thought that type='network' and type='bridge' could be conflated for interface actual type, but this turned out to be too problematic to do). Signed-off-by: Laine Stump <laine(a)redhat.com> --- (NB: I thought I remembered seeing a bugzilla report go by about this regression, but couldn't find it in any of the places I frequent (upstream, Fedora, or RHEL) If someone can locate it and wants to let me know the BZ#, I can add it to the commit message and update the report). (This fixes the reconnect of taps to their bridges, but the count maintained in the network object still isn't being updated in these cases. I've tried removing the !virUUIDIsValid() check in this same chunk, along with preserving the original port uuid if it's already valid in virDomainNetDefActualToNetworkPort(), and that results in fixing the usage count for type='network' when it's a libvirt-managed bridge or a macvtap passthrough pool, but leads to errors in other cases.) src/conf/domain_conf.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 848c831330..24223bceb2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30971,13 +30971,16 @@ virDomainNetNotifyActualDevice(virConnectPtr conn, virDomainDefPtr dom, virDomainNetDefPtr iface) { + virDomainNetType actualType = virDomainNetGetActualType(iface); + if (!virUUIDIsValid(iface->data.network.portid)) { if (virDomainNetCreatePort(conn, dom, iface, VIR_NETWORK_PORT_CREATE_RECLAIM) < 0) return; } - if (virDomainNetGetActualType(iface) == VIR_DOMAIN_NET_TYPE_BRIDGE) { + if (actualType == VIR_DOMAIN_NET_TYPE_NETWORK || + actualType == VIR_DOMAIN_NET_TYPE_BRIDGE) { /* * NB: we can't notify the guest of any MTU change anyway, * so there is no point in trying to learn the actualMTU -- 2.21.0

2 1

[libvirt] [PATCH 0/2] a few cleanups in qemu_domain_address.c
by Daniel Henrique Barboza 20 Sep '19

20 Sep '19

First patch is the standard "use VIR_AUTOFREE() in strings" type of patch. Second one is something I tried it out and ended up cleaning some repetitive code, so I believe it's worth seeing what you think. Daniel Henrique Barboza (2): qemu_domain_address.c: use VIR_AUTOFREE() in strings virpci, qemu_domain_address: adding virPCIDeviceSetAddress src/libvirt_private.syms | 1 + src/qemu/qemu_domain_address.c | 126 +++++++++++++++------------------ src/util/virpci.c | 10 +++ src/util/virpci.h | 3 + 4 files changed, 70 insertions(+), 70 deletions(-) -- 2.21.0

2 5