[PATCH] virdomainjob: check if cb is not NULL before dereferencing
by Kristina Hanicova
The callback struct does not always have to be set which could
cause a dereferencing of a NULL pointer. This patch adds check
against NULL in missing places before dereferencing.
Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com>
---
src/conf/virdomainjob.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/conf/virdomainjob.c b/src/conf/virdomainjob.c
index 0c67e84ef1..ca0215bc23 100644
--- a/src/conf/virdomainjob.c
+++ b/src/conf/virdomainjob.c
@@ -626,7 +626,7 @@ virDomainObjEndJob(virDomainObj *obj)
virDomainObjResetJob(obj->job);
- if (virDomainTrackJob(job) &&
+ if (virDomainTrackJob(job) && obj->job->cb &&
obj->job->cb->saveStatusPrivate)
obj->job->cb->saveStatusPrivate(obj);
/* We indeed need to wake up ALL threads waiting because
@@ -662,7 +662,7 @@ virDomainObjEndAsyncJob(virDomainObj *obj)
obj, obj->def->name);
virDomainObjResetAsyncJob(obj->job);
- if (obj->job->cb->saveStatusPrivate)
+ if (obj->job->cb && obj->job->cb->saveStatusPrivate)
obj->job->cb->saveStatusPrivate(obj);
virCondBroadcast(&obj->job->asyncCond);
}
--
2.37.3
2 years, 2 months
[PATCH] NEWS: Document my contributions for upcoming release
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
NEWS.rst | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 69c5b70c2f..81c95859ff 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -25,6 +25,11 @@ v8.8.0 (unreleased)
* **Improvements**
+ * qemu: Implement VIR_DOMAIN_STATS_CPU_TOTAL for qemu:///session
+
+ Users can now query VIR_DOMAIN_STATS_CPU_TOTAL (also known as cpu.time)
+ statistics for session domains.
+
* **Bug fixes**
* qemu: Fix non-shared storage migration setup
@@ -33,6 +38,26 @@ v8.8.0 (unreleased)
( ``virsh migrate --copy-storage-all``) which was broken by a refactor of
the code in libvirt-8.7.
+ * selinux: Don't ignore NVMe disks when setting image label
+
+ Libvirt did not set any SELinux label on NVMe disks and relied only on the
+ default SELinux policy. This turned out to cause problem when using
+ namespace or altered policy and thus is fixed now.
+
+ * qemu: Fix a deadlock when setting up namespace
+
+ When starting a domain, libvirt creates a mount namespace and manages
+ private /dev with only a handful nodes exposed. But when creating those a
+ deadlock inside glib might have occurred. The code was changed so that
+ libvirt does not tickle the glib bug.
+
+ * qemu: Don't build memory paths on daemon restart
+
+ When the daemon is restarted it tried to create domain private paths for
+ each mounted hugetlbfs. When this failed, the corresponding domain was
+ killed. This operation is now performed during domain startup and memory
+ hotplug and no longer leads to sudden kill of the domain.
+
v8.7.0 (2022-09-01)
===================
--
2.35.1
2 years, 2 months
[PATCH] docs: add firmware feature flags
by Gerd Hoffmann
Add new firmware feature flags for the recently added confidential
computing operating modes by amd and intel.
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
docs/interop/firmware.json | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
index 4e049b1c7ca0..657082b78b83 100644
--- a/docs/interop/firmware.json
+++ b/docs/interop/firmware.json
@@ -121,6 +121,15 @@
# related to this feature are documented in
# "docs/amd-memory-encryption.txt".
#
+# @amd-sev-snp: The firmware supports running under AMD Secure Encrypted
+# Virtualization - Secure Nested Paging, as specified in the
+# AMD64 Architecture Programmer's Manual. QEMU command line
+# options related to this feature are documented in
+# "docs/amd-memory-encryption.txt".
+#
+# @intel-tdx: The firmware supports running under Intel Trust Domain
+# Extensions (TDX).
+#
# @enrolled-keys: The variable store (NVRAM) template associated with
# the firmware binary has the UEFI Secure Boot
# operational mode turned on, with certificates
@@ -185,9 +194,11 @@
# Since: 3.0
##
{ 'enum' : 'FirmwareFeature',
- 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'amd-sev-es', 'enrolled-keys',
- 'requires-smm', 'secure-boot', 'verbose-dynamic',
- 'verbose-static' ] }
+ 'data' : [ 'acpi-s3', 'acpi-s4',
+ 'amd-sev', 'amd-sev-es', 'amd-sev-snp',
+ 'intel-tdx',
+ 'enrolled-keys', 'requires-smm', 'secure-boot',
+ 'verbose-dynamic', 'verbose-static' ] }
##
# @FirmwareFlashFile:
--
2.37.3
2 years, 2 months
Entering freeze for libvirt-8.8.0
by Jiri Denemark
I have just tagged v8.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
2 years, 2 months
[PATCH] docs: compiling: Add link to latest openSUSE libvirt package
by Jim Fehlig
This is a follow-up to fbd6b2480a, adding a link to the latest libvirt
package for openSUSE.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
docs/compiling.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/docs/compiling.rst b/docs/compiling.rst
index bc43a929da..2a740ad76e 100644
--- a/docs/compiling.rst
+++ b/docs/compiling.rst
@@ -24,6 +24,10 @@ allow installing the most recent versions of virtualization packages:
The ``app-emulation/libvirt`` is regularly updated, but newest versions are
usually marked as testing by the ``~*`` keyword.
+ **openSUSE**
+
+ Refer to https://build.opensuse.org/package/show/Virtualization/libvirt
+
Preparing sources
-----------------
--
2.37.1
2 years, 2 months
[PATCH] qemuNamespaceMknodOne: Call g_file_read_link() in async-signal-safe fashion
by Michal Privoznik
When creating a node in QEMU's namespace the whole link chain is
created with it. Here, we use g_file_read_link() from the child
(running inside the namespace) to learn whether a link exists and
points to expected target. Now, when building the namespace there
can't be any symlinks and this g_file_read_link() returns NULL
always. And because we pass a local GError variable to it, glib
tries to set it to a localized error message. This comes with
creating a (static) hash table inside of g_strerror() and is
guarded with a mutex. The hash table is also allocated using
GSlice allocator instead of g_malloc, and since the latter is
safe to use after fork (because it's documented to use plain
malloc), glib went with the former, naturally. Now, GSlice
allocator has plenty of internal mutexes and thus hitting a
locked mutex is not that hard.
Fortunately, we don't care about any error from
g_file_read_link() and thus we can pass NULL which avoids calling
g_strerror().
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2120965
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_namespace.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c
index a2c31310d9..311c66d46e 100644
--- a/src/qemu/qemu_namespace.c
+++ b/src/qemu/qemu_namespace.c
@@ -957,10 +957,9 @@ qemuNamespaceMknodOne(qemuNamespaceMknodItem *data)
}
if (isLink) {
- g_autoptr(GError) gerr = NULL;
g_autofree char *target = NULL;
- if ((target = g_file_read_link(data->file, &gerr)) &&
+ if ((target = g_file_read_link(data->file, NULL)) &&
STREQ(target, data->target)) {
VIR_DEBUG("Skipping symlink %s -> %s which exists and points to correct target",
data->file, data->target);
--
2.35.1
2 years, 2 months
Re: [PATCH v2] rpc: fix memory leak in virNetServerClientNew and virNetServerProgramDispatchCall
by Michal Prívozník
On 9/30/22 04:32, Jiang Jiacheng wrote:
> I see, maybe we could free dispatcher->arg_filter and
> dispatcher->ret_filter together in error label like this:
> error:
> if (dispatcher) {
> xdr_free(dispatcher->arg_filter, arg);
> xdr_free(dispatcher->ret_filter, ret);
> }
> and in successful path, we can free them before return.
Yes, this is what I tested just before suggesting it.
Michal
2 years, 2 months
[libvirt] [PATCH v2] qemu: Remove host-passthrough validation check for host-phys-bits=on
by Lin Ma
Besides the -cpu host, The host-phys-bits=on applies to custom or max
cpu model, So the host-passthrough validation check is unnecessary for
maxphysaddr with mode='passthrough'.
Signed-off-by: Lin Ma <lma(a)suse.com>
---
src/qemu/qemu_validate.c | 7 -------
.../cpu-phys-bits-passthrough2.err | 2 +-
.../cpu-phys-bits-passthrough2.xml | 4 ++--
.../cpu-phys-bits-passthrough3.err | 1 -
.../cpu-phys-bits-passthrough3.xml | 20 -------------------
tests/qemuxml2argvtest.c | 1 -
6 files changed, 3 insertions(+), 32 deletions(-)
delete mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err
delete mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 3327f6e24f..34fa10ae32 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -344,13 +344,6 @@ qemuValidateDomainDefCpu(virQEMUDriver *driver,
switch (addr->mode) {
case VIR_CPU_MAX_PHYS_ADDR_MODE_PASSTHROUGH:
- if (def->cpu->mode != VIR_CPU_MODE_HOST_PASSTHROUGH) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("CPU maximum physical address bits mode '%s' can only be used with '%s' CPUs"),
- virCPUMaxPhysAddrModeTypeToString(addr->mode),
- virCPUModeTypeToString(VIR_CPU_MODE_HOST_PASSTHROUGH));
- return -1;
- }
if (addr->bits != -1) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("CPU maximum physical address bits number specification cannot be used with mode='%s'"),
diff --git a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err
index 22009cc6e6..28f2e43432 100644
--- a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err
+++ b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err
@@ -1 +1 @@
-unsupported configuration: CPU maximum physical address bits mode 'passthrough' can only be used with 'host-passthrough' CPUs
+unsupported configuration: CPU maximum physical address bits number specification cannot be used with mode='passthrough'
diff --git a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml
index 511bbf9949..a94e567dcb 100644
--- a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml
+++ b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml
@@ -8,8 +8,8 @@
<type arch='x86_64' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
- <cpu mode='host-model'>
- <maxphysaddr mode='passthrough'/>
+ <cpu mode='host-passthrough'>
+ <maxphysaddr mode='passthrough' bits='42'/>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
diff --git a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err
deleted file mode 100644
index 28f2e43432..0000000000
--- a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err
+++ /dev/null
@@ -1 +0,0 @@
-unsupported configuration: CPU maximum physical address bits number specification cannot be used with mode='passthrough'
diff --git a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml b/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml
deleted file mode 100644
index a94e567dcb..0000000000
--- a/tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml
+++ /dev/null
@@ -1,20 +0,0 @@
-<domain type='kvm'>
- <name>foo</name>
- <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
- <memory unit='KiB'>219136</memory>
- <currentMemory unit='KiB'>219136</currentMemory>
- <vcpu placement='static'>1</vcpu>
- <os>
- <type arch='x86_64' machine='pc'>hvm</type>
- <boot dev='hd'/>
- </os>
- <cpu mode='host-passthrough'>
- <maxphysaddr mode='passthrough' bits='42'/>
- </cpu>
- <clock offset='utc'/>
- <on_poweroff>destroy</on_poweroff>
- <on_reboot>restart</on_reboot>
- <on_crash>destroy</on_crash>
- <devices>
- </devices>
-</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index b7c3bc0e2d..c8b69bbd7a 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -3240,7 +3240,6 @@ mymain(void)
DO_TEST("cpu-phys-bits-emulate2", QEMU_CAPS_KVM);
DO_TEST_PARSE_ERROR("cpu-phys-bits-emulate3", QEMU_CAPS_KVM);
DO_TEST_PARSE_ERROR("cpu-phys-bits-passthrough2", QEMU_CAPS_KVM);
- DO_TEST_PARSE_ERROR("cpu-phys-bits-passthrough3", QEMU_CAPS_KVM);
if (getenv("LIBVIRT_SKIP_CLEANUP") == NULL)
virFileDeleteTree(fakerootdir);
--
2.26.2
2 years, 2 months
[PATCH] qemuNamespaceMknodPaths: Don't fork needlessly
by Michal Privoznik
The qemuNamespaceMknodPaths() function is responsible for
creating files/directories in QEMU's mount namespace. When
called, it is given list of paths that have to be created in the
namespace. It processes this list and removes items that are not
directly under /dev, but on a 'shared' filesystem (note that all
other mount points are preserved). And it may so happen that
after this pre-process no files/directories need to be created in
the namespace. If that's the case, exit early and avoid
fork()-ing only to find out the same.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c
index 09e235e120..a2c31310d9 100644
--- a/src/qemu/qemu_namespace.c
+++ b/src/qemu/qemu_namespace.c
@@ -1293,6 +1293,9 @@ qemuNamespaceMknodPaths(virDomainObj *vm,
goto cleanup;
}
+ if (data.nitems == 0)
+ return 0;
+
for (i = 0; i < data.nitems; i++) {
qemuNamespaceMknodItem *item = &data.items[i];
if (item->target &&
--
2.35.1
2 years, 2 months
[PATCH] qemuProcessReconnect: Don't build memory paths
by Michal Privoznik
Let me take you on a short trip to history. A long time ago,
libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu
for their hugepages setup. This was problematic, because it did
not allow enough separation between guests. Therefore in
v3.0.0-rc1~367 the path changed to a per-domain basis:
$hugetlbfs/libvirt/qemu/$domainShortName
And to help with migration on daemon restart a call to
qemuProcessBuildDestroyMemoryPaths() was added to
qemuProcessReconnect() (well, it was named
qemuProcessBuildDestroyHugepagesPath() back then, see
v3.10.0-rc1~174). This was desirable then, because the memory
hotplug code did not call the function, it simply assumes
per-domain paths to exist. But this changed in v3.5.0-rc1~92
after which the per-domain paths are created on memory hotplug
too.
Therefore, it's no longer necessary to create these paths in
qemuProcessReconnect(). They are created exactly when needed
(domain startup and memory hotplug).
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_process.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index b05ad059c3..998f4aa63c 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -8785,9 +8785,6 @@ qemuProcessReconnect(void *opaque)
goto cleanup;
}
- if (qemuProcessBuildDestroyMemoryPaths(driver, obj, NULL, true) < 0)
- goto error;
-
if ((qemuDomainAssignAddresses(obj->def, priv->qemuCaps,
driver, obj, false)) < 0) {
goto error;
--
2.35.1
2 years, 2 months
