June 2021 - Devel - libvirt List Archives

[PATCH] meson.build: Remove the -Wvla-larger-then flag
by Thomas Huth 08 Jun '21

08 Jun '21

The flag has a typo in it, it's "...-than=..." and not "...-then=...", so this was in fact never used. Since we're also using -Wvla (without size), we should already get warnings about any variable length arrays anyway, so the additional "-Wvla-larger-than" does not make much sense and thus we can simply drop this. Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- meson.build | 1 - 1 file changed, 1 deletion(-) diff --git a/meson.build b/meson.build index 4f23f9104e..40c841e777 100644 --- a/meson.build +++ b/meson.build @@ -390,7 +390,6 @@ cc_flags += [ '-Wvariadic-macros', '-Wvector-operation-performance', '-Wvla', - '-Wvla-larger-then=4031', '-Wvolatile-register-var', '-Wwrite-strings', ] -- 2.27.0

4 4

[PATCH 0/3] libxl: A few firmware improvments
by Jim Fehlig 08 Jun '21

08 Jun '21

Upstream ovmf will be removing support for Xen in the traditional ovmf package, moving it to a separate OvmfXen package https://bugzilla.tianocore.org/show_bug.cgi?id=2122 This motivated me to verify the impact on libvirt+ovmf+xen. Fortunately it is minimal since the new OvmfXen package is basically a reduced version of the traditional package. I.e. it should contain everything the traditional package contains and thus is binary compatible and should not affect existing guests using the traditional package. Indeed my initial testing has shown this to be true. While testing I cooked up a few improvements to the libxl driver firmware handling, including adding support for automatic firmware selection. Thanks for review/comments! Jim Fehlig (3): libxl: Introduce domain def validate callback libxl: Forbid domain definition with secure boot enabled libxl: Support firmware autoselection src/libxl/libxl_conf.c | 17 ++++++++++++-- src/libxl/libxl_domain.c | 49 ++++++++++++++++++++++++++++++++-------- 2 files changed, 54 insertions(+), 12 deletions(-) -- 2.31.1

2 4

[libvirt PATCH] meson: Ask rst2html to strip comments
by Andrea Bolognani 08 Jun '21

08 Jun '21

They can be problematic: in particular, the rst files generated by keycodemapdb's keymap-gen contain things like To re-generate, run: keymap-gen --lang=rst --title=virkeycode-osx [...] which result in xsltproc later choking with [1/12] Generating virkeyname-osx.html with a meson_exe.py custom command FAILED: docs/manpages/virkeyname-osx.html /usr/bin/meson --internal exe --capture docs/manpages/virkeyname-osx.html \ /usr/bin/xsltproc [...] --nonet ../docs/subsite.xsl docs/manpages/virkeyname-osx.html.in docs/manpages/virkeyname-osx.html.in:17: parser error : Double hyphen within comment: keymap-gen --lang=rst --title=virkeyname-osx [...] ^ Stripping comments avoids the issue entirely. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/manpages/meson.build | 2 +- docs/meson.build | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/manpages/meson.build b/docs/manpages/meson.build index 0fa93fad89..eda0aa8441 100644 --- a/docs/manpages/meson.build +++ b/docs/manpages/meson.build @@ -118,7 +118,7 @@ foreach data : docs_man_files html_in_file, input: rst_file, output: html_in_file, - command: [ rst2html_prog, '--stylesheet=', '--strict', '@INPUT@' ], + command: [ rst2html_prog, '--strip-comments', '--stylesheet=', '--strict', '@INPUT@' ], capture: true, ) diff --git a/docs/meson.build b/docs/meson.build index f550629d8e..c94a3c7f13 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -185,7 +185,7 @@ docs_admin_api_xml = docs_api_generated[3] docs_rst2html_gen = generator( rst2html_prog, output: '@BASENAME@.html.in', - arguments: [ '--stylesheet=', '--strict', '@INPUT@' ], + arguments: [ '--strip-comments', '--stylesheet=', '--strict', '@INPUT@' ], capture: true, ) -- 2.31.1

4 6

[libvirt PATCH] openvswitch: don't delete existing OVS port prior to recreating same port
by Laine Stump 08 Jun '21

08 Jun '21

Connecting a tap device to an Open vSwitch is done by adding a "port" to the switch with the ovs-vsctl "add-port" command. The port will have the same name as the tap device, but it is a separate entity, and can survive beyond the destruction of the tap device (although under normal circumstances the port will be deleted around the same time the tap device is deleted). This makes it possible for a port of a particular name to already exist at the time libvirt calls ovs-vsctl to add that port. The original commit of Open vSwitch support (commit df81004632, libvirt 0.9.10, Feb. 2012) used the "--may-exist" option to the add-port command to indicate that a port of the desired name might already exist, and that it was okay to simply re-use this port (rather than failing with an error message). Then in commit 33445ce8446d9 (libvirt 1.2.7, April 2014) the command was changed to use "--if-exists del-port blah" instead of "--may-exist". The reason given was that there was a bug in OVS where a stale port would be unusable even though it still existed; the workaround was to forcibly delete any existing port prior to adding the new port (of the same name). This is the ovs-vsctl command still in use by libvirt today. It recently came up in the discussion of a bug concerning guest packet loss during OpenStack upgrades (https://bugzilla.redhat.com/1963164) that the bug in OVS that necessitated the del-port workaround was fixed quite a long time ago (August 2015): https://github.com/openvswitch/ovs/commit/e21c6643a02c6b446d2fbdfde366ea303… thus rendering the workaround in libvirt unnecessary. The assertion in that discussion is that this workaround is now the cause of the packet loss being experienced during OpenStack upgrades. I'm not convinced this is the case, but it does appear that there is no reason to carry this workaround in libvirt any longer, so this patch reverts the code back to the original behavior (using "--may-exist" instead of "--if-exists del-port"). Signed-off-by: Laine Stump <laine(a)redhat.com> --- In an attempt to sabotage my own patch, I will point out that this makes it a possibility that libvirt could end up using an OVS port created by "someone else" who may have set it up in some way that renders the guest network connection unusable, e.g. if the port had been created with flow filters or something. On the other hand 1) the "someone else" in this scenario would need to have all the same privileges that would also permit them to mess up the connection after it had been created (so there is no *extra* security risk), and 2) this could possibly be *desired* (although difficult for libvirt to support) behavior in the case someone needed libvirt-managed guest network connections to use extra capabilities not directly supported in libvirt's config; additionally pre-creating the OVS port could provide a method of getting the network connection into a usable state (i.e. forwarding traffic) much sooner. src/util/virnetdevopenvswitch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c index 21ee4bdd42..eac68d9556 100644 --- a/src/util/virnetdevopenvswitch.c +++ b/src/util/virnetdevopenvswitch.c @@ -155,8 +155,8 @@ int virNetDevOpenvswitchAddPort(const char *brname, const char *ifname, } cmd = virNetDevOpenvswitchCreateCmd(); - virCommandAddArgList(cmd, "--", "--if-exists", "del-port", - ifname, "--", "add-port", brname, ifname, NULL); + virCommandAddArgList(cmd, "--", "--may-exist", + "add-port", brname, ifname, NULL); virNetDevOpenvswitchConstructVlans(cmd, virtVlan); -- 2.31.1

2 1

[PATCH v2] tools: only fail validations if VIR_HOST_VALIDATE_FAIL is set
by Fabiano Fidêncio 08 Jun '21

08 Jun '21

Currently `virt-host-validate` will fail whenever one of its calls fail, regardless of virHostValidateLevel set. This behaviour is not optimal and makes it not exactly reliable as a command line tool as other tools or scripts using it would have to check its output to figure out whether something really failed or if a warning was mistakenly treated as failure. With this change, the behaviour of whether to fail or not, is defined by the caller of those functions, based on the virHostValidateLevel passed to them. https://gitlab.com/libvirt/libvirt/-/issues/175 Signed-off-by: Fabiano Fidêncio <fabiano(a)fidencio.org> --- Changes since v1: * Replace the `goto out;` and the `out` labels by the `VIR_HOST_VALIDATE_FAILURE` macro --- tools/virt-host-validate-common.c | 30 +++++++++++++++--------------- tools/virt-host-validate-common.h | 14 ++++++++++++++ 2 files changed, 29 insertions(+), 15 deletions(-) diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c index 6dd851f07d..9412bb7514 100644 --- a/tools/virt-host-validate-common.c +++ b/tools/virt-host-validate-common.c @@ -142,7 +142,7 @@ int virHostValidateDeviceExists(const char *hvname, if (access(dev_name, F_OK) < 0) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } virHostMsgPass(); @@ -159,7 +159,7 @@ int virHostValidateDeviceAccessible(const char *hvname, if (access(dev_name, R_OK|W_OK) < 0) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } virHostMsgPass(); @@ -180,7 +180,7 @@ int virHostValidateNamespace(const char *hvname, if (access(nspath, F_OK) < 0) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } virHostMsgPass(); @@ -264,17 +264,17 @@ int virHostValidateLinuxKernel(const char *hvname, if (STRNEQ(uts.sysname, "Linux")) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } if (virParseVersionString(uts.release, &thisversion, true) < 0) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } if (thisversion < version) { virHostMsgFail(level, "%s", hint); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } else { virHostMsgPass(); return 0; @@ -291,7 +291,7 @@ int virHostValidateCGroupControllers(const char *hvname, size_t i; if (virCgroupNew("/", -1, &group) < 0) - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); for (i = 0; i < VIR_CGROUP_CONTROLLER_LAST; i++) { int flag = 1 << i; @@ -303,7 +303,7 @@ int virHostValidateCGroupControllers(const char *hvname, virHostMsgCheck(hvname, "for cgroup '%s' controller support", cg_name); if (!virCgroupHasController(group, i)) { - ret = -1; + ret = VIR_HOST_VALIDATE_FAILURE(level); virHostMsgFail(level, "Enable '%s' in kernel Kconfig file or " "mount/enable cgroup controller in your system", cg_name); @@ -320,7 +320,7 @@ int virHostValidateCGroupControllers(const char *hvname G_GNUC_UNUSED, virHostValidateLevel level) { virHostMsgFail(level, "%s", "This platform does not support cgroups"); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } #endif /* !__linux__ */ @@ -354,7 +354,7 @@ int virHostValidateIOMMU(const char *hvname, "No ACPI DMAR table found, IOMMU either " "disabled in BIOS or not supported by this " "hardware platform"); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } } else if (isAMD) { virHostMsgCheck(hvname, "%s", _("for device assignment IOMMU support")); @@ -366,7 +366,7 @@ int virHostValidateIOMMU(const char *hvname, "No ACPI IVRS table found, IOMMU either " "disabled in BIOS or not supported by this " "hardware platform"); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } } else if (ARCH_IS_PPC64(arch)) { /* Empty Block */ @@ -385,7 +385,7 @@ int virHostValidateIOMMU(const char *hvname, } else { virHostMsgFail(level, "Unknown if this platform has IOMMU support"); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } @@ -404,7 +404,7 @@ int virHostValidateIOMMU(const char *hvname, "Add %s to kernel cmdline arguments", bootarg); else virHostMsgFail(level, "IOMMU capability not compiled into kernel."); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } virHostMsgPass(); return 0; @@ -468,7 +468,7 @@ int virHostValidateSecureGuests(const char *hvname, } if (virFileReadValueString(&cmdline, "/proc/cmdline") < 0) - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); /* we're prefix matching rather than equality matching here, because * kernel would treat even something like prot_virt='yFOO' as @@ -516,7 +516,7 @@ int virHostValidateSecureGuests(const char *hvname, } else { virHostMsgFail(level, "Unknown if this platform has Secure Guest support"); - return -1; + return VIR_HOST_VALIDATE_FAILURE(level); } return 0; diff --git a/tools/virt-host-validate-common.h b/tools/virt-host-validate-common.h index 08a9997f5f..9334fa8588 100644 --- a/tools/virt-host-validate-common.h +++ b/tools/virt-host-validate-common.h @@ -45,6 +45,20 @@ typedef enum { VIR_ENUM_DECL(virHostValidateCPUFlag); +/** + * VIR_HOST_VALIDATE_FAILURE + * @level: the virHostValidateLevel to be checked + * + * This macro is to be used in to return a failures based on the + * virHostValidateLevel use in the function. + * + * If the virHostValidateLevel is VIR_HOST_VALIDATE_FAIL, -1 is returned. + * 0 is returned otherwise (as the virHosValidateLevel is then either a + * Warn or a Note). + */ + +#define VIR_HOST_VALIDATE_FAILURE(level) (level == VIR_HOST_VALIDATE_FAIL) ? -1 : 0 + void virHostMsgSetQuiet(bool quietFlag); void virHostMsgCheck(const char *prefix, -- 2.31.1

2 2

[libvirt PATCH v3] docs: introduce stubs for new libvirt Go packages
by Daniel P. Berrangé 07 Jun '21

07 Jun '21

Currently we expose libvirt Go packages at libvirt.org/libvirt-go libvirt.org/libvirt-go-xml These packages have not supported Go modules historically and when we tried to introduce modules, we hit the problem that we're not using semver for versioning. The only way around this is to introduce new packages under a different namespace, that will have the exact same code, but be tagged with a different version numbering scheme. This change proposes: libvirt.org/go/libvirt libvirt.org/go/libvirtxml Note the hyphen is removed so that the import basename matches the Go package name. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/go/libvirt.rst | 19 +++++++++++++++ docs/go/libvirtxml.rst | 16 +++++++++++++ docs/go/meson.build | 53 +++++++++++++++++++++++++++++++++++++++++ docs/libvirt-go-xml.rst | 24 ++++++++++++++----- docs/libvirt-go.rst | 23 ++++++++++++++---- docs/meson.build | 1 + 6 files changed, 125 insertions(+), 11 deletions(-) create mode 100644 docs/go/libvirt.rst create mode 100644 docs/go/libvirtxml.rst create mode 100644 docs/go/meson.build diff --git a/docs/go/libvirt.rst b/docs/go/libvirt.rst new file mode 100644 index 0000000000..6a1344ad3e --- /dev/null +++ b/docs/go/libvirt.rst @@ -0,0 +1,19 @@ +========================================= +Libvirt Go Language API (with Go modules) +========================================= + +The `Go <https://golang.org/>`__ package ``libvirt.org/go/libvirt`` provides +`CGo <https://golang.org/cmd/cgo/>`__ binding from the OS native Libvirt API. + +This package replaces the obsolete `libvirt.org/libvirt-go +<../libvirt-go.html>`__ package in order to switch to using `semver +<https://semver.org/>`__ and `Go modules <https://golang.org/ref/mod>`__. +Aside from the changed import path and versioning scheme, the API is fully +compatible with the legacy package. + +In general the Go representation is a direct 1-1 mapping from native API +concepts to Go, so the native API documentation should serve as a reference +for most behaviour. + +For details of Go specific behaviour consult the +`Go package documentation <https://pkg.go.dev/libvirt.org/go/libvirt>`__. diff --git a/docs/go/libvirtxml.rst b/docs/go/libvirtxml.rst new file mode 100644 index 0000000000..5407d609f2 --- /dev/null +++ b/docs/go/libvirtxml.rst @@ -0,0 +1,16 @@ +============================================ +Libvirt Go XML parsing API (with Go modules) +============================================ + +The `Go <https://golang.org/>`__ package ``libvirt.org/go/libvirtxml`` provides +annotated Go struct definitions for parsing (and formatting) XML documents used +with libvirt APIs. + +This package replaces the obsolete `libvirt.org/libvirt-go-xml +<../libvirt-go-xml.html>`__ package in order to switch to using `semver +<https://semver.org/>`__ and `Go modules <https://golang.org/ref/mod>`__. +Aside from the changed import path and versioning scheme, the API is fully +compatible with the original package. + +For details of Go specific behaviour consult the +`Go package documentation <https://pkg.go.dev/libvirt.org/go/libvirtxml>`__. diff --git a/docs/go/meson.build b/docs/go/meson.build new file mode 100644 index 0000000000..d2accd322b --- /dev/null +++ b/docs/go/meson.build @@ -0,0 +1,53 @@ +docs_go_files = [ + 'libvirt', + 'libvirtxml', +] + +html_xslt_gen_xslt = subsite_xsl +html_xslt_gen_install_dir = docs_html_dir / 'go' +html_xslt_gen = [] + +foreach name : docs_go_files + rst_file = '@0@.rst'.format(name) + + html_xslt_gen += { + 'name': name, + 'file': docs_rst2html_gen.process(rst_file), + 'source': 'docs' / 'go' / rst_file, + } +endforeach + +# keep the XSLT processing code block in sync with docs/meson.build + +# --- begin of XSLT processing --- + +foreach data : html_xslt_gen + html_filename = data['name'] + '.html' + + html_file = custom_target( + html_filename, + input: data.get('file', data['name'] + '.html.in'), + output: html_filename, + command: [ + xsltproc_prog, + '--stringparam', 'pagesrc', data.get('source', ''), + '--stringparam', 'builddir', meson.build_root(), + '--stringparam', 'timestamp', docs_timestamp, + '--nonet', + html_xslt_gen_xslt, + '@INPUT@', + ], + depends: data.get('depends', []), + depend_files: [ page_xsl ], + capture: true, + install: true, + install_dir: html_xslt_gen_install_dir, + ) + + install_web_deps += html_file + install_web_files += html_file.full_path() + ':' + html_xslt_gen_install_dir +endforeach + +html_xslt_gen = [] + +# --- end of XSLT processing --- diff --git a/docs/libvirt-go-xml.rst b/docs/libvirt-go-xml.rst index 995fdd2b07..43ebf50765 100644 --- a/docs/libvirt-go-xml.rst +++ b/docs/libvirt-go-xml.rst @@ -1,10 +1,22 @@ -========================== -Libvirt Go XML parsing API -========================== +=================================================== +Obsolete libvirt Go XML parsing API (no Go modules) +=================================================== -The `Go <https://golang.org/>`__ package ``libvirt.org/libvirt-go-xml`` provides -annotated Go struct definitions for parsing (and formatting) XML documents used -with libvirt APIs. +This obsolete `Go <https://golang.org/>`__ package ``libvirt.org/libvirt-go-xml`` +provided annotated Go struct definitions for parsing (and formatting) XML +documents used with libvirt APIs. + +This package is replaced by the new `libvirt.org/go/libvirtxml +<go/libvirtxml.html>`__ package in order to switch to using `semver +<https://semver.org/>`__ and `Go modules <https://golang.org/ref/mod>`__. +Aside from the changed import path and versioning scheme, the new package API +is fully compatible with this legacy package. + +Software currently using this package will keep working, but no further +development will take place. libvirt XML scheme elements/attributes introduced +after 7.4.0 will never be available. Authors are strongly recommended to switch +imports to point to the new package, to prepare for future Go toolchains +which will mandate Go module support and semver. For details of Go specific behaviour consult the `Go package documentation <https://pkg.go.dev/libvirt.org/libvirt-go-xml>`__. diff --git a/docs/libvirt-go.rst b/docs/libvirt-go.rst index f2d3f80fb2..7dd78b5f6e 100644 --- a/docs/libvirt-go.rst +++ b/docs/libvirt-go.rst @@ -1,9 +1,22 @@ -======================= -Libvirt Go Language API -======================= +================================================ +Obsolete libvirt Go Language API (no Go modules) +================================================ -The `Go <https://golang.org/>`__ package ``libvirt.org/libvirt-go`` provides -`CGo <https://golang.org/cmd/cgo/>`__ binding from the OS native Libvirt API. +This obsolete `Go <https://golang.org/>`__ package ``libvirt.org/libvirt-go`` +provided `CGo <https://golang.org/cmd/cgo/>`__ binding from the OS native +Libvirt API. + +This package is replaced by the new `libvirt.org/go/libvirt <go/libvirt.html>`__ +package in order to switch to using `semver <https://semver.org/>`__ and +`Go modules <https://golang.org/ref/mod>`__. Aside from the changed +import path and versioning scheme, the new package API is fully compatible +with this legacy package. + +Software currently using this package will keep working, but no further +development will take place. libvirt APIs/constants introduced after +7.4.0 will never be available. Authors are strongly recommended to switch +imports to point to the new package, to prepare for future Go toolchains +which will mandate Go module support and semver. In general the Go representation is a direct 1-1 mapping from native API concepts to Go, so the native API documentation should serve as a reference diff --git a/docs/meson.build b/docs/meson.build index bee0d80d53..4497f7270f 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -297,6 +297,7 @@ html_xslt_gen = [] # --- end of XSLT processing --- subdir('fonts') +subdir('go') subdir('html') subdir('internals') subdir('js') -- 2.31.1

2 1

[PATCH v8 0/3] qemu: Support rbd namespace
by Han Han 07 Jun '21

07 Jun '21

Diff from v7: - Squash a commit - Rebase to latest code v7: https://listman.redhat.com/archives/libvir-list/2020-November/msg00480.html Han Han (3): qemu_capabilities: Add QEMU_CAPS_RBD_NAMESPACE conf: Support to parse rbd namespace from source name qemu: Implement rbd namespace to the source name attribute docs/formatdomain.rst | 16 ++++++ src/conf/domain_conf.c | 47 +++++++++++++++-- src/conf/storage_source_conf.c | 2 + src/conf/storage_source_conf.h | 1 + src/qemu/qemu_block.c | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 8 +++ .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + ...k-network-rbd-namespace.x86_64-latest.args | 38 ++++++++++++++ .../disk-network-rbd-namespace.xml | 40 +++++++++++++++ tests/qemuxml2argvtest.c | 1 + ...sk-network-rbd-namespace.x86_64-latest.xml | 50 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 27 files changed, 218 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-namespace.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-namespace.xml create mode 100644 tests/qemuxml2xmloutdata/disk-network-rbd-namespace.x86_64-latest.xml -- 2.31.1

2 7

[PATCH] remote: remove/annotate unused variables
by Daniel P. Berrangé 07 Jun '21

07 Jun '21

Fixes commit 48f66cfe3ee51baf64f06f1f89dda52af6f4d9d6 Fixes commit fcdcf8f70cf5d6657086e2889124d0e1a7332a29 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/remote/remote_driver.c | 3 --- src/rpc/virnetsocket.c | 2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index da672b0d00..c03c68ec30 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -729,9 +729,6 @@ doRemoteOpen(virConnectPtr conn, virConf *conf, unsigned int flags) { -#ifndef WIN32 - g_autofree char *daemonPath = NULL; -#endif g_autofree char *tls_priority = NULL; g_autofree char *name = NULL; g_autofree char *command = NULL; diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index c3fae8b626..212089520d 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -774,7 +774,7 @@ int virNetSocketNewConnectUNIX(const char *path, } #else int virNetSocketNewConnectUNIX(const char *path G_GNUC_UNUSED, - const char *spawnDaemonPath, + const char *spawnDaemonPath G_GNUC_UNUSED, virNetSocket **retsock G_GNUC_UNUSED) { virReportSystemError(ENOSYS, "%s", -- 2.31.1

2 1

[PATCH] ch: set driver to NULL after freeing it
by Daniel P. Berrangé 07 Jun '21

07 Jun '21

If the chStateInitialize method fails, we call chStateCleanup which free's all global state. It fails to set the global 'ch_driver' to NULL, however, so a later attempt to open the cloud hypervisor driver will succeed and then crash attempting to access freed memory. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/ch/ch_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/ch/ch_driver.c b/src/ch/ch_driver.c index 8c458a20bd..1ee33817f9 100644 --- a/src/ch/ch_driver.c +++ b/src/ch/ch_driver.c @@ -827,6 +827,7 @@ static int chStateCleanup(void) virObjectUnref(ch_driver->config); virMutexDestroy(&ch_driver->lock); g_free(ch_driver); + ch_driver = NULL; return 0; } -- 2.31.1

2 1

[libvirt PATCH] docs: virtiofs: describe memfd memory backend
by Stefan Hajnoczi 07 Jun '21

07 Jun '21

Nowadays memfd is the most convenient memory backend for vhost-user devices. Compared to file-backend memory and hugepages, there is no need to worry about configuring the location of the shm directory or allocating hugepages. Cc: Michal Prívozník <mprivozn(a)redhat.com> Cc: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha(a)gmail.com> --- docs/kbase/virtiofs.rst | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/kbase/virtiofs.rst b/docs/kbase/virtiofs.rst index 740b08d50d..8cf7567bf8 100644 --- a/docs/kbase/virtiofs.rst +++ b/docs/kbase/virtiofs.rst @@ -29,7 +29,11 @@ NUMA. As of QEMU 5.0.0 and libvirt 6.9.0, it is possible to specify the memory backend without NUMA (using the so called memobject interface). -Either of the following: +One of the following: + +* Use memfd memory + + No host setup is required when using the Linux memfd memory backend. * Use file-backed memory @@ -75,7 +79,20 @@ Guest setup #. Specify the memory backend - Either of the following: + One of the following: + + * memfd memory + + :: + + <domain> + ... + <memoryBacking> + <source type='memfd'/> + <access mode='shared'/> + </memoryBacking> + ... + </domain> * File-backed memory -- 2.31.1

2 1