[PATCH 1/3] qemu: add a 'chain' parameter to nbdkit start/stop
by Jonathon Jongsma
This will allow us to start or stop nbdkit for just a single disk source
or for every source in the backing chain. This will be used in following
patches.
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
src/qemu/qemu_extdevice.c | 8 +++---
src/qemu/qemu_hotplug.c | 6 ++---
src/qemu/qemu_nbdkit.c | 51 ++++++++++++++++++++++++++++++---------
src/qemu/qemu_nbdkit.h | 6 +++--
4 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
index 3cf3867056..ed5976d1f7 100644
--- a/src/qemu/qemu_extdevice.c
+++ b/src/qemu/qemu_extdevice.c
@@ -234,12 +234,12 @@ qemuExtDevicesStart(virQEMUDriver *driver,
for (i = 0; i < def->ndisks; i++) {
virDomainDiskDef *disk = def->disks[i];
- if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0)
return -1;
}
if (def->os.loader && def->os.loader->nvram) {
- if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram, true) < 0)
return -1;
}
@@ -297,11 +297,11 @@ qemuExtDevicesStop(virQEMUDriver *driver,
for (i = 0; i < def->ndisks; i++) {
virDomainDiskDef *disk = def->disks[i];
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
}
if (def->os.loader && def->os.loader->nvram)
- qemuNbdkitStopStorageSource(def->os.loader->nvram, vm);
+ qemuNbdkitStopStorageSource(def->os.loader->nvram, vm, true);
}
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 31b00e05ca..e67673b762 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1018,7 +1018,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver,
if (qemuHotplugAttachManagedPR(vm, disk->src, VIR_ASYNC_JOB_NONE) < 0)
goto cleanup;
- if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0)
goto cleanup;
}
@@ -1045,7 +1045,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver,
if (virStorageSourceChainHasManagedPR(disk->src))
ignore_value(qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE));
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
}
qemuDomainSecretDiskDestroy(disk);
qemuDomainCleanupStorageSourceFD(disk->src);
@@ -4562,7 +4562,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriver *driver,
qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE) < 0)
goto cleanup;
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
if (disk->transient) {
VIR_DEBUG("Removing transient overlay '%s' of disk '%s'",
diff --git a/src/qemu/qemu_nbdkit.c b/src/qemu/qemu_nbdkit.c
index 1c72b6fe6a..39f9c58a48 100644
--- a/src/qemu/qemu_nbdkit.c
+++ b/src/qemu/qemu_nbdkit.c
@@ -893,18 +893,34 @@ qemuNbdkitInitStorageSource(qemuNbdkitCaps *caps WITHOUT_NBDKIT_UNUSED,
}
+static int
+qemuNbdkitStartStorageSourceOne(virQEMUDriver *driver,
+ virDomainObj *vm,
+ virStorageSource *src)
+{
+ qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src);
+
+ if (priv && priv->nbdkitProcess &&
+ qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0)
+ return -1;
+
+ return 0;
+}
+
+
int
qemuNbdkitStartStorageSource(virQEMUDriver *driver,
virDomainObj *vm,
- virStorageSource *src)
+ virStorageSource *src,
+ bool chain)
{
virStorageSource *backing;
- for (backing = src; backing != NULL; backing = backing->backingStore) {
- qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing);
+ if (!chain)
+ return qemuNbdkitStartStorageSourceOne(driver, vm, src);
- if (priv && priv->nbdkitProcess &&
- qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0)
+ for (backing = src; backing != NULL; backing = backing->backingStore) {
+ if (qemuNbdkitStartStorageSourceOne(driver, vm, backing) < 0)
return -1;
}
@@ -912,18 +928,31 @@ qemuNbdkitStartStorageSource(virQEMUDriver *driver,
}
+static void
+qemuNbdkitStopStorageSourceOne(virStorageSource *src,
+ virDomainObj *vm)
+{
+ qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src);
+
+ if (priv && priv->nbdkitProcess &&
+ qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0)
+ VIR_WARN("Unable to stop nbdkit for storage source '%s'",
+ qemuBlockStorageSourceGetStorageNodename(src));
+}
+
+
void
qemuNbdkitStopStorageSource(virStorageSource *src,
- virDomainObj *vm)
+ virDomainObj *vm,
+ bool chain)
{
virStorageSource *backing;
- for (backing = src; backing != NULL; backing = backing->backingStore) {
- qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing);
+ if (! chain)
+ return qemuNbdkitStopStorageSourceOne(src, vm);
- if (priv && priv->nbdkitProcess &&
- qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0)
- VIR_WARN("Unable to stop nbdkit for storage source '%s'", qemuBlockStorageSourceGetStorageNodename(src));
+ for (backing = src; backing != NULL; backing = backing->backingStore) {
+ qemuNbdkitStopStorageSourceOne(backing, vm);
}
}
diff --git a/src/qemu/qemu_nbdkit.h b/src/qemu/qemu_nbdkit.h
index 853b2cca6f..637bf962a7 100644
--- a/src/qemu/qemu_nbdkit.h
+++ b/src/qemu/qemu_nbdkit.h
@@ -63,11 +63,13 @@ qemuNbdkitReconnectStorageSource(virStorageSource *source,
int
qemuNbdkitStartStorageSource(virQEMUDriver *driver,
virDomainObj *vm,
- virStorageSource *src);
+ virStorageSource *src,
+ bool chain);
void
qemuNbdkitStopStorageSource(virStorageSource *src,
- virDomainObj *vm);
+ virDomainObj *vm,
+ bool chain);
int
qemuNbdkitStorageSourceManageProcess(virStorageSource *src,
--
2.43.0
3 months, 1 week
[PATCH 0/5] tests: More USB and capabilities for s390x
by Andrea Bolognani
*** UNIVERSAL SERIAL BLURB ***
https://gitlab.com/abologna/libvirt/-/commits/caps-s390x
Andrea Bolognani (5):
tests: Rename s390-usb-*
tests: Minimize s390-usb-*
tests: Add s390-usb-model
tests: Update capabilities for QEMU 8.1.0 on s390x
tests: Add capabilities for QEMU 8.2.0 on s390x
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 80 +-
...u_8.1.0.s390x.xml => qemu_8.2.0.s390x.xml} | 152 +-
.../caps_8.1.0_s390x.replies | 5000 +++++----
.../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 732 +-
...s390x.replies => caps_8.2.0_s390x.replies} | 9526 ++++++++++-------
...s_8.1.0_s390x.xml => caps_8.2.0_s390x.xml} | 2058 ++--
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
.../s390-allow-bogus-usb-controller.xml | 32 -
.../s390-allow-bogus-usb-none.xml | 30 -
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
...rgs => s390-usb-address.s390x-latest.args} | 9 -
....xml => s390-usb-address.s390x-latest.xml} | 22 +-
tests/qemuxmlconfdata/s390-usb-address.xml | 15 +
....args => s390-usb-model.s390x-latest.args} | 11 +-
...st.xml => s390-usb-model.s390x-latest.xml} | 26 +-
tests/qemuxmlconfdata/s390-usb-model.xml | 13 +
...t.args => s390-usb-none.s390x-latest.args} | 12 +-
...est.xml => s390-usb-none.s390x-latest.xml} | 22 +-
tests/qemuxmlconfdata/s390-usb-none.xml | 13 +
tests/qemuxmlconftest.c | 5 +-
24 files changed, 10053 insertions(+), 7717 deletions(-)
copy tests/domaincapsdata/{qemu_8.1.0.s390x.xml => qemu_8.2.0.s390x.xml} (79%)
copy tests/qemucapabilitiesdata/{caps_8.1.0_s390x.replies => caps_8.2.0_s390x.replies} (93%)
copy tests/qemucapabilitiesdata/{caps_8.1.0_s390x.xml => caps_8.2.0_s390x.xml} (96%)
delete mode 100644 tests/qemuxmlconfdata/s390-allow-bogus-usb-controller.xml
delete mode 100644 tests/qemuxmlconfdata/s390-allow-bogus-usb-none.xml
rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-none.s390x-latest.args => s390-usb-address.s390x-latest.args} (58%)
copy tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.xml => s390-usb-address.s390x-latest.xml} (55%)
create mode 100644 tests/qemuxmlconfdata/s390-usb-address.xml
rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.args => s390-usb-model.s390x-latest.args} (58%)
rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.xml => s390-usb-model.s390x-latest.xml} (51%)
create mode 100644 tests/qemuxmlconfdata/s390-usb-model.xml
copy tests/qemuxmlconfdata/{s390-defaultconsole.s390x-latest.args => s390-usb-none.s390x-latest.args} (61%)
rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-none.s390x-latest.xml => s390-usb-none.s390x-latest.xml} (50%)
create mode 100644 tests/qemuxmlconfdata/s390-usb-none.xml
--
2.43.0
3 months, 1 week
[PULL 02/10] docs: mark CRIS support as deprecated
by Alex Bennée
This might be premature but while streamlining the avocado tests I
realised the only tests we have are "check-tcg" ones. The ageing
fedora-cris-cross image works well enough for developers but can't be
used in CI as we need supported build platforms to build QEMU.
Does this mean the writing is on the wall for this architecture?
Cc: Rabin Vincent <rabinv(a)axis.com>
Reviewed-by: Thomas Huth <thuth(a)redhat.com>
Acked-by: Edgar E. Iglesias <edgar.iglesias(a)gmail.com>
Reviewed-by: Thomas Huth <thuth(a)redhat.com>
Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org>
Message-Id: <20240207163812.3231697-3-alex.bennee(a)linaro.org>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index c7b95e6068e..7b0c59919e5 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -192,6 +192,13 @@ in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``,
an alias, but for consistency these will get removed in a future
release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead.
+CRIS CPU architecture (since 9.0)
+'''''''''''''''''''''''''''''''''
+
+The CRIS architecture was pulled from Linux in 4.17 and the compiler
+is no longer packaged in any distro making it harder to run the
+``check-tcg`` tests. Unless we can improve the testing situation there
+is a chance the code will bitrot without anyone noticing.
System emulator machines
------------------------
--
2.39.2
3 months, 1 week
[PATCH v2] docs: Improve documentation for dies and clusters
by Andrea Bolognani
I've seen examples in the wild of the cluster attribute having
non-zero value on x86_64.
This is obviously quite confusing, but it's the information that
Linux exposes to userspace and we don't really have a way to tell
apart a valid die/cluster ID from a dummy one.
What ultimately matters is that the underlying assumptions about
topology are respected, which they are: in the x86_64 cases that
I have analyzed, for example, each "cluster" contained exactly
one core, so any program that would use this information to
influence guest topology decisions would be unaffected by the
additional level showing up in the hierarchy.
In an attempt to reduce confusion, remove any reference to any
specific value for the attributes having any special meaning
attached to it.
In fact, since there are plans to make it possible to create
guests with multiple CPU clusters on x86_64, rework the note
into a more generic warning cautioning users that an attribute
showing up here does not imply that the same attribute can be
used when defining a guest CPU topology.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/formatcaps.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index f37532296f..68477e639f 100644
--- a/docs/formatcaps.rst
+++ b/docs/formatcaps.rst
@@ -74,14 +74,14 @@ The ``<host/>`` element consists of the following child elements:
``die_id``
Identifier for the die the CPU is in.
- Note that not all architectures support CPU dies: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, even if this attribute is present, you might not be able to
+ define guests with multiple CPU dies.
``cluster_id``
Identifier for the cluster the CPU is in.
- Note that not all architectures support CPU clusters: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, even if this attribute is present, you might not be able to
+ define guests with multiple CPU clusters.
``core_id``
Identifier for the core the CPU is in.
--
2.43.0
3 months, 1 week
[PATCH] docs: Improve documentation for dies and clusters
by Andrea Bolognani
I've seen examples in the wild of the cluster attribute having
non-zero value on x86_64.
This is obviously quite confusing, but it's the information that
Linux exposes to userspace and we don't really have a way to tell
apart a valid die/cluster ID from a dummy one.
What ultimately matters is that the underlying assumptions about
topology are respected, which they are: in the x86_64 cases that
I have analyzed, for example, each "cluster" contained exactly
one core, so any program that would use this information to
influence guest topology decisions would be unaffected by the
additional level showing up in the hierarchy.
In an attempt to reduce confusion, document that the value for
these attributes is not necessarily going to be zero.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/formatcaps.rst | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index f37532296f..c15d391b63 100644
--- a/docs/formatcaps.rst
+++ b/docs/formatcaps.rst
@@ -74,14 +74,18 @@ The ``<host/>`` element consists of the following child elements:
``die_id``
Identifier for the die the CPU is in.
- Note that not all architectures support CPU dies: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, while not all architectures support CPU dies, this attribute
+ will always be present in the capabilities XML. If the architecture
+ doesn't support them, the value will likely be 0 for all CPUs, but it
+ could also be some other arbitrary value.
``cluster_id``
Identifier for the cluster the CPU is in.
- Note that not all architectures support CPU clusters: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, while not all architectures support CPU clusters, this
+ attribute will always be present in the capabilities XML. If the
+ architecture doesn't support them, the value will likely be 0 for all
+ CPUs, but it could also be some other arbitrary value.
``core_id``
Identifier for the core the CPU is in.
--
2.43.0
3 months, 1 week
[libvirt PATCH 0/2] ci: lcitool: sync dependencies with libvirt-ci repo
by Ján Tomko
Ján Tomko (2):
ci: lcitool: sync dependencies with libvirt-ci repo
ci: regenerate
ci/buildenv/almalinux-8.sh | 1 +
ci/buildenv/alpine-319.sh | 1 +
ci/buildenv/alpine-edge.sh | 1 +
ci/buildenv/centos-stream-8.sh | 1 +
ci/buildenv/centos-stream-9.sh | 1 +
ci/buildenv/debian-11-cross-aarch64.sh | 1 +
ci/buildenv/debian-11-cross-armv6l.sh | 1 +
ci/buildenv/debian-11-cross-armv7l.sh | 1 +
ci/buildenv/debian-11-cross-i686.sh | 1 +
ci/buildenv/debian-11-cross-mips64el.sh | 1 +
ci/buildenv/debian-11-cross-mipsel.sh | 1 +
ci/buildenv/debian-11-cross-ppc64le.sh | 1 +
ci/buildenv/debian-11-cross-s390x.sh | 1 +
ci/buildenv/debian-11.sh | 1 +
ci/buildenv/debian-12-cross-aarch64.sh | 1 +
ci/buildenv/debian-12-cross-armv6l.sh | 1 +
ci/buildenv/debian-12-cross-armv7l.sh | 1 +
ci/buildenv/debian-12-cross-i686.sh | 1 +
ci/buildenv/debian-12-cross-mips64el.sh | 1 +
ci/buildenv/debian-12-cross-mipsel.sh | 1 +
ci/buildenv/debian-12-cross-ppc64le.sh | 1 +
ci/buildenv/debian-12-cross-s390x.sh | 1 +
ci/buildenv/debian-12.sh | 1 +
ci/buildenv/debian-sid-cross-aarch64.sh | 1 +
ci/buildenv/debian-sid-cross-armv6l.sh | 1 +
ci/buildenv/debian-sid-cross-armv7l.sh | 1 +
ci/buildenv/debian-sid-cross-i686.sh | 1 +
ci/buildenv/debian-sid-cross-mips64el.sh | 1 +
ci/buildenv/debian-sid-cross-ppc64le.sh | 1 +
ci/buildenv/debian-sid-cross-s390x.sh | 1 +
ci/buildenv/debian-sid.sh | 1 +
ci/buildenv/fedora-38-cross-mingw32.sh | 1 +
ci/buildenv/fedora-38-cross-mingw64.sh | 1 +
ci/buildenv/fedora-38.sh | 1 +
ci/buildenv/fedora-39.sh | 1 +
ci/buildenv/fedora-rawhide-cross-mingw32.sh | 1 +
ci/buildenv/fedora-rawhide-cross-mingw64.sh | 1 +
ci/buildenv/fedora-rawhide.sh | 1 +
ci/buildenv/opensuse-leap-15.sh | 1 +
ci/buildenv/opensuse-tumbleweed.sh | 1 +
ci/buildenv/ubuntu-2004.sh | 1 +
ci/buildenv/ubuntu-2204.sh | 1 +
ci/containers/almalinux-8.Dockerfile | 1 +
ci/containers/alpine-319.Dockerfile | 1 +
ci/containers/alpine-edge.Dockerfile | 1 +
ci/containers/centos-stream-8.Dockerfile | 1 +
ci/containers/centos-stream-9.Dockerfile | 1 +
ci/containers/debian-11-cross-aarch64.Dockerfile | 3 ++-
ci/containers/debian-11-cross-armv6l.Dockerfile | 3 ++-
ci/containers/debian-11-cross-armv7l.Dockerfile | 3 ++-
ci/containers/debian-11-cross-i686.Dockerfile | 3 ++-
ci/containers/debian-11-cross-mips64el.Dockerfile | 3 ++-
ci/containers/debian-11-cross-mipsel.Dockerfile | 3 ++-
ci/containers/debian-11-cross-ppc64le.Dockerfile | 3 ++-
ci/containers/debian-11-cross-s390x.Dockerfile | 3 ++-
ci/containers/debian-11.Dockerfile | 1 +
ci/containers/debian-12-cross-aarch64.Dockerfile | 3 ++-
ci/containers/debian-12-cross-armv6l.Dockerfile | 3 ++-
ci/containers/debian-12-cross-armv7l.Dockerfile | 3 ++-
ci/containers/debian-12-cross-i686.Dockerfile | 3 ++-
ci/containers/debian-12-cross-mips64el.Dockerfile | 3 ++-
ci/containers/debian-12-cross-mipsel.Dockerfile | 3 ++-
ci/containers/debian-12-cross-ppc64le.Dockerfile | 3 ++-
ci/containers/debian-12-cross-s390x.Dockerfile | 3 ++-
ci/containers/debian-12.Dockerfile | 1 +
ci/containers/debian-sid-cross-aarch64.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-armv6l.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-armv7l.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-i686.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-mips64el.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-ppc64le.Dockerfile | 3 ++-
ci/containers/debian-sid-cross-s390x.Dockerfile | 3 ++-
ci/containers/debian-sid.Dockerfile | 1 +
ci/containers/fedora-38-cross-mingw32.Dockerfile | 3 ++-
ci/containers/fedora-38-cross-mingw64.Dockerfile | 3 ++-
ci/containers/fedora-38.Dockerfile | 1 +
ci/containers/fedora-39.Dockerfile | 1 +
ci/containers/fedora-rawhide-cross-mingw32.Dockerfile | 3 ++-
ci/containers/fedora-rawhide-cross-mingw64.Dockerfile | 3 ++-
ci/containers/fedora-rawhide.Dockerfile | 1 +
ci/containers/opensuse-leap-15.Dockerfile | 1 +
ci/containers/opensuse-tumbleweed.Dockerfile | 1 +
ci/containers/ubuntu-2004.Dockerfile | 1 +
ci/containers/ubuntu-2204.Dockerfile | 1 +
ci/lcitool/projects/libvirt+minimal.yml | 2 +-
ci/lcitool/projects/libvirt.yml | 5 +++--
86 files changed, 115 insertions(+), 30 deletions(-)
--
2.43.0
3 months, 1 week
[libvirt PATCH] qemu: Add support for /dev/userfaultfd
by Jiri Denemark
/dev/userfaultfd device is preferred over userfaultfd syscall for
post-copy migrations. Unless qemu driver is configured to disable mount
namespace or to forbid access to /dev/userfaultfd in cgroup_device_acl,
we will copy it to the limited /dev filesystem QEMU will have access to
and label it appropriately. So in the default configuration post-copy
migration will be allowed even without enabling
vm.unprivileged_userfaultfd sysctl.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
Notes:
The question is what should we do with the
src/qemu/postcopy-migration.sysctl file which is installed by
libvirt.spec to /usr/lib/sysctl.d/60-qemu-postcopy-migration.conf by
default. The file is now useless and should ideally be removed, but only
when the host kernel is new enough to support /dev/userfaultfd
src/qemu/qemu.conf.in | 3 +-
src/qemu/qemu_cgroup.c | 1 +
src/qemu/qemu_process.c | 38 +++++++++++++++++++++++++
src/qemu/qemu_security.c | 45 ++++++++++++++++++++++++++++++
src/qemu/qemu_security.h | 5 ++++
src/qemu/test_libvirtd_qemu.aug.in | 1 +
6 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in
index 34025a02ef..f406df8749 100644
--- a/src/qemu/qemu.conf.in
+++ b/src/qemu/qemu.conf.in
@@ -565,7 +565,8 @@
#cgroup_device_acl = [
# "/dev/null", "/dev/full", "/dev/zero",
# "/dev/random", "/dev/urandom",
-# "/dev/ptmx", "/dev/kvm"
+# "/dev/ptmx", "/dev/kvm",
+# "/dev/userfaultfd"
#]
#
# RDMA migration requires the following extra files to be added to the list:
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index 47402b3750..5a5ba763a0 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -41,6 +41,7 @@ const char *const defaultDeviceACL[] = {
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm",
+ "/dev/userfaultfd",
NULL,
};
#define DEVICE_PTY_MAJOR 136
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 0a6c18a671..6e51d6586b 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2882,6 +2882,40 @@ qemuProcessStartManagedPRDaemon(virDomainObj *vm)
}
+static int
+qemuProcessAllowPostCopyMigration(virDomainObj *vm)
+{
+ qemuDomainObjPrivate *priv = vm->privateData;
+ virQEMUDriver *driver = priv->driver;
+ g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver);
+ const char *const *devices = (const char *const *) cfg->cgroupDeviceACL;
+ const char *uffd = "/dev/userfaultfd";
+ int rc;
+
+ if (!virFileExists(uffd)) {
+ VIR_DEBUG("%s is not supported by the host", uffd);
+ return 0;
+ }
+
+ if (!devices)
+ devices = defaultDeviceACL;
+
+ if (!g_strv_contains(devices, uffd)) {
+ VIR_DEBUG("%s is not allowed by device ACL", uffd);
+ return 0;
+ }
+
+ VIR_DEBUG("Labeling %s in mount namespace", uffd);
+ if ((rc = qemuSecurityDomainSetMountNSPathLabel(driver, vm, uffd)) < 0)
+ return -1;
+
+ if (rc == 1)
+ VIR_DEBUG("Mount namespace is not enabled, leaving %s as is", uffd);
+
+ return 0;
+}
+
+
static int
qemuProcessInitPasswords(virQEMUDriver *driver,
virDomainObj *vm,
@@ -7802,6 +7836,10 @@ qemuProcessLaunch(virConnectPtr conn,
qemuProcessStartManagedPRDaemon(vm) < 0)
goto cleanup;
+ VIR_DEBUG("Setting up permissions to allow post-copy migration");
+ if (qemuProcessAllowPostCopyMigration(vm) < 0)
+ goto cleanup;
+
VIR_DEBUG("Setting domain security labels");
if (qemuSecuritySetAllLabel(driver,
vm,
diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c
index 8bcef14d08..4aaa863ae9 100644
--- a/src/qemu/qemu_security.c
+++ b/src/qemu/qemu_security.c
@@ -615,6 +615,51 @@ qemuSecurityDomainRestorePathLabel(virQEMUDriver *driver,
}
+/**
+ * qemuSecurityDomainSetMountNSPathLabel:
+ *
+ * Label given path in mount namespace. If mount namespace is not enabled,
+ * nothing is labeled at all.
+ *
+ * Because the label is only applied in mount namespace, there's no need to
+ * restore it.
+ *
+ * Returns 0 on success,
+ * 1 when mount namespace is not enabled,
+ * -1 on error.
+ */
+int
+qemuSecurityDomainSetMountNSPathLabel(virQEMUDriver *driver,
+ virDomainObj *vm,
+ const char *path)
+{
+ int ret = -1;
+
+ if (!qemuDomainNamespaceEnabled(vm, QEMU_DOMAIN_NS_MOUNT)) {
+ VIR_DEBUG("Not labeling '%s': mount namespace disabled for domain '%s'",
+ path, vm->def->name);
+ return 1;
+ }
+
+ if (virSecurityManagerTransactionStart(driver->securityManager) < 0)
+ goto cleanup;
+
+ if (virSecurityManagerDomainSetPathLabel(driver->securityManager,
+ vm->def, path, false) < 0)
+ goto cleanup;
+
+ if (virSecurityManagerTransactionCommit(driver->securityManager,
+ vm->pid, false) < 0)
+ goto cleanup;
+
+ ret = 0;
+
+ cleanup:
+ virSecurityManagerTransactionAbort(driver->securityManager);
+ return ret;
+}
+
+
/**
* qemuSecurityCommandRun:
* @driver: the QEMU driver
diff --git a/src/qemu/qemu_security.h b/src/qemu/qemu_security.h
index 10f11771b4..41da33debc 100644
--- a/src/qemu/qemu_security.h
+++ b/src/qemu/qemu_security.h
@@ -110,6 +110,11 @@ int qemuSecurityDomainRestorePathLabel(virQEMUDriver *driver,
virDomainObj *vm,
const char *path);
+int
+qemuSecurityDomainSetMountNSPathLabel(virQEMUDriver *driver,
+ virDomainObj *vm,
+ const char *path);
+
int qemuSecurityCommandRun(virQEMUDriver *driver,
virDomainObj *vm,
virCommand *cmd,
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
index e4cfde6cc7..b97e6de11e 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -67,6 +67,7 @@ module Test_libvirtd_qemu =
{ "5" = "/dev/urandom" }
{ "6" = "/dev/ptmx" }
{ "7" = "/dev/kvm" }
+ { "8" = "/dev/userfaultfd" }
}
{ "save_image_format" = "raw" }
{ "dump_image_format" = "raw" }
--
2.43.0
3 months, 1 week
[PATCH 00/11] webpage related fixes
by Peter Krempa
Patch 1 fixes the 'maven' redirect for gitlab pages by adding a /. Note
that I didn't test that yet as it's hard to do with the redirects file,
so this one will be tested in produciton.
The rest of the series optimizes JS, CSS and XSLT assets for reuse in
libvirt wiki by separating out stuff that is relevant only for
libvirt.org. There will be a corresponding merge request to pull them
into the wiki project.
The resulting page can be browsed at:
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/6119138205/artifacts/website/i...
https://gitlab.com/pipo.sk/libvirt/-/pipelines/1168193309
Peter Krempa (11):
gitlab_pages: Fix 'maven' redirect
docs: page.xsl: Fix headerlinks with new docutils
js: Separate the virt-tools blog planet loader code
css: mobile: Split up libvirt.org specific styles from main template
style
css: Split out page templated styles to 'libvirt-template.css'
css: Remove unused CSS for migration support matrix table
css: Move styles for the generated API documents to libvirt-api.css
css: Move generic styles to 'generic.css'
docs: Move 'html including' from page.xsl to site.xsl
docs: xsl: Properly propagate 'href_base' as XSL template parameter
docs: page.xsl: Split up 'href_base' for assets and links
.gitlab_pages_redirects | 2 +-
docs/css/generic.css | 59 +++
docs/css/libvirt-api.css | 112 +++++
docs/css/libvirt-template.css | 236 +++++++++++
docs/css/libvirt.css | 417 -------------------
docs/css/main.css | 5 +-
docs/css/meson.build | 5 +-
docs/css/mobile-libvirt.css | 17 +
docs/css/{mobile.css => mobile-template.css} | 15 +-
docs/html/meson.build | 2 +
docs/index.rst | 5 +-
docs/js/main.js | 62 ---
docs/js/meson.build | 1 +
docs/js/virt-tools-blog-planet.js | 65 +++
docs/newapi.xsl | 3 +-
docs/page.xsl | 37 +-
docs/site.xsl | 17 +-
17 files changed, 535 insertions(+), 525 deletions(-)
create mode 100644 docs/css/libvirt-api.css
create mode 100644 docs/css/libvirt-template.css
create mode 100644 docs/css/mobile-libvirt.css
rename docs/css/{mobile.css => mobile-template.css} (84%)
create mode 100644 docs/js/virt-tools-blog-planet.js
--
2.43.0
3 months, 1 week
volume default permissions
by Memet Bilgin
Hello all,
this is a feature request for something that was evidently discussed then
dismissed a while back (c.f.
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5Y...
)
The feature/bug in the above thread is a succinct description of the issue
and I will not elaborate on it much, however this statement:
> at this point changing the defaults could surprise some people and the
current behavior hasn't generated many complaints, so best to just leave it
as is.
doesn't make much sense.
I get that default behaviour should be backwards compatible.
However, there is a legitimate need for this feature when using libvirt
remotely (e.g via terraform over qemu:// or qemu+ssh://) as the users of
the remote API don't have access to the uid's of the user and group and
this means that as things are, a remote user can *only* reliably use
root:root as the permission - else they need to use a hard coded magic
number or have access to the host.
Explicitly specifying -1 in the XML as the user and group ids should make
the volume inherit the pool ids. This is completely backwards compatible
because any such value being literally interpreted in the legacy code base
would have resulted in an error anyways.
What are your thoughts?
Regards,
Memet Bilgin
3 months, 1 week
