[PATCH 0/3] libxl: A few firmware improvments
by Jim Fehlig
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
3 years, 5 months
[libvirt PATCH] meson: Ask rst2html to strip comments
by Andrea Bolognani
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
3 years, 5 months
[libvirt PATCH] openvswitch: don't delete existing OVS port prior to recreating same port
by Laine Stump
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/e21c6643a02c6b446d2fbdfde366ea3...
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
3 years, 5 months
[PATCH v2] tools: only fail validations if VIR_HOST_VALIDATE_FAIL is set
by Fabiano Fidêncio
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
3 years, 5 months
[libvirt PATCH v3] docs: introduce stubs for new libvirt Go packages
by Daniel P. Berrangé
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
3 years, 5 months
[PATCH v8 0/3] qemu: Support rbd namespace
by Han Han
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
3 years, 5 months
[PATCH] remote: remove/annotate unused variables
by Daniel P. Berrangé
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
3 years, 5 months
[PATCH] ch: set driver to NULL after freeing it
by Daniel P. Berrangé
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
3 years, 5 months
[libvirt PATCH] docs: virtiofs: describe memfd memory backend
by Stefan Hajnoczi
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
3 years, 5 months
[libvirt] [PATCH 0/2] virsh: Add coredump format completion to dump
by Lin Ma
Lin Ma (2):
virsh: Use VIR_ENUM_* for --format argument in doDump
virsh: Add coredump format completion to dump command
tools/virsh-completer-domain.c | 19 +++++++++++++++++++
tools/virsh-completer-domain.h | 5 +++++
tools/virsh-domain.c | 28 ++++++++++++++--------------
tools/virsh-domain.h | 1 +
4 files changed, 39 insertions(+), 14 deletions(-)
--
2.26.2
3 years, 5 months
