[PATCH 0/2] Fix storage_file_backend_fs demodularization
by Peter Krempa
2 bugs were missed; brown paper bag was installed
Peter Krempa (2):
libvirt.spec: Move ownership of 'storage-file' backends directory to
gluster
storage_file_backend_fs: Compile out 'chown' backend on mingw
libvirt.spec.in | 2 +-
src/storage_file/storage_file_backend_fs.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.48.1
3 weeks
[PATCH v2 0/2] tests: Add qemu-9.2 dev cycle caps on s390x
by Michal Privoznik
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/WA...
diff to v1:
- instead of switching test case from 2.7 machine type to something
newer, just drop the test case.
Michal Prívozník (2):
qemuxmlconftest: Drop s390-default-cpu-...ccw-virtio-2.7 test cases
tests: qemucapabilities: Add test data for the qemu-9.2 dev cycle on
s390x
tests/domaincapsdata/qemu_9.3.0.s390x.xml | 436 +
.../caps_9.3.0_s390x.replies | 38101 ++++++++++++++++
.../qemucapabilitiesdata/caps_9.3.0_s390x.xml | 4268 ++
...-deprecated-features-off.s390x-latest.args | 2 +-
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 32 -
...lt-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml | 25 -
.../s390-default-cpu-kvm-ccw-virtio-2.7.xml | 16 -
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 32 -
...lt-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml | 27 -
.../s390-default-cpu-tcg-ccw-virtio-2.7.xml | 16 -
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 2 -
17 files changed, 42812 insertions(+), 157 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_9.3.0.s390x.xml
create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.replies
create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.xml
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.args
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.xml
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.args
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml
delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.xml
--
2.45.2
3 weeks
[PATCH] util: avoid overflow in hextable buffer
by Daniel P. Berrangé
The assigned string is 17 chars long once the trailing nul is taken
into account. This triggers a warning with GCC 15
src/util/virsystemd.c: In function ‘virSystemdEscapeName’:
src/util/virsystemd.c:59:38: error: initializer-string for array of ‘char’ is too long [-Werror=unterminated-string-initialization]
59 | static const char hextable[16] = "0123456789abcdef";
| ^~~~~~~~~~~~~~~~~~
Switch to a dynamically sized array as used in all the other places
we have a hextable array.
See also: https://gcc.gnu.org/PR115185
Reported-by: Yaakov Selkowitz <yselkowi(a)redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/util/virsystemd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
index 5b772e29dd..d46e5f74fc 100644
--- a/src/util/virsystemd.c
+++ b/src/util/virsystemd.c
@@ -56,7 +56,7 @@ struct _virSystemdActivationEntry {
static void virSystemdEscapeName(virBuffer *buf,
const char *name)
{
- static const char hextable[16] = "0123456789abcdef";
+ static const char hextable[] = "0123456789abcdef";
#define ESCAPE(c) \
do { \
--
2.47.1
3 weeks
[libvirt PATCH] meson: error out when ch driver is requested but unsupported
by Ján Tomko
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
meson.build | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 16ec3ba7e2..326d9dd0f9 100644
--- a/meson.build
+++ b/meson.build
@@ -1582,8 +1582,12 @@ elif get_option('driver_lxc').enabled()
error('linux and remote_driver are required for LXC')
endif
-if not get_option('driver_ch').disabled() and host_machine.system() == 'linux' and (host_machine.cpu_family() == 'x86_64' or host_machine.cpu_family() == 'aarch64')
- use_ch = true
+if not get_option('driver_ch').disabled()
+ if host_machine.system() == 'linux' and (host_machine.cpu_family() == 'x86_64' or host_machine.cpu_family() == 'aarch64')
+ use_ch = true
+ elif get_option('driver_ch').enabled()
+ error('linux on x86_64 or aarch64 is required to build Cloud-Hypervisor driver')
+ endif
if not conf.has('WITH_LIBVIRTD')
use_ch = false
--
2.47.0
3 weeks
[PATCH] spec: Only build ch driver on x86_64 and aarch64
by Cole Robinson
This matches the cpu_family() check in `meson.build`
Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
---
note: something probably needs to be fixed on meson.build side too,
since an explicit `driver_ch=enabled` doesn't generate a build
error.
libvirt.spec.in | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 2bc8dfd323..5a1755d74f 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -29,6 +29,7 @@
%define arches_zfs %{arches_x86} %{power64} %{arm}
%define arches_numactl %{arches_x86} %{power64} aarch64 s390x
%define arches_numad %{arches_x86} %{power64} aarch64
+%define arches_ch x86_64 aarch64
# The hypervisor drivers that run in libvirtd
%define with_qemu 0%{!?_without_qemu:1}
@@ -124,6 +125,9 @@
%ifnarch %{arches_ceph}
%define with_storage_rbd 0
%endif
+%ifnarch %{arches_ch}
+ %define with_ch 0
+%endif
# RHEL doesn't ship many hypervisor drivers
%if 0%{?rhel}
--
2.48.1
3 weeks
[PATCH 0/4] Implement virsh hypervisor-cpu-models
by Boris Fiuczynski
Allows for the query of hypervisor-known CPU models via the simple
command: virsh hypervisor-cpu-models. For the QEMU driver, the models
are queried via the capabilities file. Each model is printed to the
terminal on its own line similar to the cpu-models command, and there
is no order to the listing.
There is a related libvirt-python merge request at
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/159
David Judkovics (4):
libvirt: Introduce virConnectGetHypervisorCPUModelNames public API
remote: Implement virConnectGetHypervisorCPUModelNames
qemu_driver: Implement qemuConnectGetHypervisorCPUModelNames
virsh: Introduce new hypervisor-cpu-models command
docs/manpages/virsh.rst | 20 ++++++++
include/libvirt/libvirt-host.h | 7 +++
src/driver-hypervisor.h | 10 ++++
src/libvirt-host.c | 65 +++++++++++++++++++++++++
src/libvirt_public.syms | 5 ++
src/qemu/qemu_driver.c | 59 +++++++++++++++++++++++
src/remote/remote_daemon_dispatch.c | 62 ++++++++++++++++++++++++
src/remote/remote_driver.c | 52 ++++++++++++++++++++
src/remote/remote_protocol.x | 26 +++++++++-
src/remote_protocol-structs | 16 +++++++
tools/virsh-host.c | 74 +++++++++++++++++++++++++++++
11 files changed, 395 insertions(+), 1 deletion(-)
--
2.47.0
3 weeks, 3 days
[PATCH 0/3] Remove deprecated machines pc-i440fx-2.4 up to pc-i440fx-2.12
by Thomas Huth
While our new auto-disablement of old machine types will only kick
in with the next (v10.1) release, the pc-i440fx-2.* machine types
have been explicitly marked as deprecated via our old deprecation
policy mechanism before (two releases ago), so it should be fine to
remove them now already.
Note that we can not do much additional clean ups on top yet since
the corresponding q35 machines (which share the same compatibility knobs)
are still around and only will be removed for the 10.1 release instead.
So the bigger clean-up can only be done for 10.1, but removing the i440fx
machine types now will still have at least a small benefit of accelerating
our CI a little bit (since we don't have to run tests for these old machine
types anymore).
Thomas Huth (3):
tests/qtest/test-x86-cpuid-compat: Remove tests related to
pc-i440fx-2.3
hw/i386/pc_piix: Remove pc-i440fx-2.4 up to pc-i440fx-2.12
tests/qtest/test-x86-cpuid-compat: Replaced the removed pc-i440fx-2.*
machines
docs/about/deprecated.rst | 7 ---
docs/about/removed-features.rst | 4 +-
docs/interop/firmware.json | 2 +-
hw/i386/pc_piix.c | 95 -----------------------------
tests/qtest/test-x86-cpuid-compat.c | 52 ++++++----------
qemu-options.hx | 10 +--
6 files changed, 25 insertions(+), 145 deletions(-)
--
2.47.1
3 weeks, 3 days
[PATCH 0/1] Support cloning saved VMs
by Felipe Franciosi
Hello!
I have a use case which I'm struggling to support with libvirt:
saving a VM to a file, cloning it (which renames the VM), and restoring it.
My search revealed a number of tutorials for using virt-clone [1], but that
doesn't seem to cover VMs which are _saved_ (only running or paused).
[1] https://github.com/virt-manager/virt-manager/blob/main/virtinst/virtclone.py
In a nutshell, I want to power on a VM and do some setup, then save its full
state to disk (e.g., with virsh save). Finally I want to modify the XML to:
- rename the VM
- change which bridge its NICs are on (while maintaining mac addresses)
- change the disk image to a copy (done while the VM is saved)
But the restore operation fails because of a target domain name check
implemented in virDomainDefCheckABIStabilityFlags(). I've debated how to best
address this and I'm looking for your views.
I suspect this call is there for a reason (which may still be relevant),
although the name is clearly not part of the ABI; it's the host identifier for
that domain and not guest-visible. My first stab at this is therefore just to
drop this check (patch attached).
I'm open to suggestions, for example by plumbing through a flag which makes the
check optional. Please let me know how you prefer that I take this forward.
Thanks,
F.
Felipe Franciosi (1):
conf: remove domain name change check on CheckABI
src/conf/domain_conf.c | 11 -----------
1 file changed, 11 deletions(-)
--
2.39.5
3 weeks, 3 days
[PATCH] cpu_x86: Probe host CPU for all MSR features
by Jiri Denemark
The list of CPU features we probe from various MSR grew significantly
over time and the CPU map currently mentions 11 distinct MSR indexes.
But the code for directly probing host CPU features was still reading
only the original 0x10a index. Thus the CPU model in host capabilities
was missing a lot of features.
Instead of specifying a static list of indexes to read (which we would
forget to update in the future), let's just read all indexes found in
the CPU map.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/cpu/cpu_x86.c | 62 ++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 53 insertions(+), 9 deletions(-)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 6d72d446c9..1ce97d9dcf 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2836,15 +2836,61 @@ cpuidSet(uint32_t base, virCPUData *data)
}
+static size_t
+virCPUx86ListMSRs(virCPUx86Map *map,
+ unsigned long **msrs)
+{
+ size_t n = 0;
+ size_t i, j, k;
+
+ /* These three nested loops look horrible, but data->len is always 1 here
+ * and thanks to grouping features in the CPU map by their MSR index the
+ * third loop will run more than one iteration only once for each distinct
+ * index.
+ */
+ for (i = 0; i < map->nfeatures; i++) {
+ virCPUx86Data *data = &map->features[i]->data;
+
+ for (j = 0; j < data->len; j++) {
+ virCPUx86DataItem *item = &data->items[j];
+ bool found = false;
+ unsigned long msr;
+
+ if (item->type != VIR_CPU_X86_DATA_MSR)
+ continue;
+
+ msr = item->data.msr.index;
+
+ for (k = n; k > 0; k--) {
+ if ((*msrs)[k - 1] == msr) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ VIR_APPEND_ELEMENT(*msrs, n, msr);
+ }
+ }
+
+ return n;
+}
+
+
static int
virCPUx86GetHost(virCPUDef *cpu,
virDomainCapsCPUModels *models)
{
g_autoptr(virCPUData) cpuData = NULL;
unsigned int addrsz;
+ virCPUx86Map *map;
+ g_autofree unsigned long *msrs = NULL;
+ size_t nmsrs;
+ uint64_t msr;
+ size_t i;
int ret;
- if (virCPUx86DriverInitialize() < 0)
+ if (!(map = virCPUx86GetMap()))
return -1;
if (!(cpuData = virCPUDataNew(archs[0])))
@@ -2854,18 +2900,16 @@ virCPUx86GetHost(virCPUDef *cpu,
cpuidSet(CPUX86_EXTENDED, cpuData) < 0)
return -1;
- /* Read the IA32_ARCH_CAPABILITIES MSR (0x10a) if supported.
- * This is best effort since there might be no way to read the MSR
- * when we are not running as root. */
- if (virCPUx86DataCheckFeature(cpuData, "arch-capabilities") == 1) {
- uint64_t msr;
- unsigned long index = 0x10a;
+ nmsrs = virCPUx86ListMSRs(map, &msrs);
- if (virHostCPUGetMSR(index, &msr) == 0) {
+ /* This is best effort since there might be no way to read the MSR
+ * when we are not running as root. */
+ for (i = 0; i < nmsrs; i++) {
+ if (virHostCPUGetMSR(msrs[i], &msr) == 0) {
virCPUx86DataItem item = {
.type = VIR_CPU_X86_DATA_MSR,
.data.msr = {
- .index = index,
+ .index = msrs[i],
.eax = msr & 0xffffffff,
.edx = msr >> 32,
},
--
2.47.1
3 weeks, 3 days
[PATCH v3 0/4] fix AppArmor policy restore for runtime rules
by Georgia Garcia
Some rules are generated dynamically during boot and added to the
AppArmor policy. An example of that is macvtap devices that call the
AppArmorSetFDLabel hook to add a rule for the tap device path.
Since this information is dynamic, it is not available in the xml
config, therefore whenever a "Restore" hook is called, the entire
profile is regenerated by virt-aa-helper based only the information
from the VM definition, so the dynamic/runtime information is lost.
This patchset fixes that by storing these rules in a different file
called libvirt-uuid.runtime_files, which is included by
libvirt-uuid.files that already exists. It also includes other fixes
like memory leaks, adoption of the GLib API in the apparmor files and
a fix on the AppArmor policy that incorrectly applies apparmor policy
syntax.
Georgia Garcia (4):
security_apparmor: fix memleaks in AppArmorSetFDLabel
security: replace uses of label and VIR_FREE by g_autofree
apparmor: fix UUID specification
virt-aa-helper: store dynamically generated rules
.../usr.lib.libvirt.virt-aa-helper.in | 5 +-
src/security/apparmor/usr.sbin.libvirtd.in | 7 +-
src/security/apparmor/usr.sbin.virtqemud.in | 6 +-
src/security/security_apparmor.c | 84 +++++-----
src/security/virt-aa-helper.c | 145 +++++++++---------
5 files changed, 125 insertions(+), 122 deletions(-)
--
2.43.0
3 weeks, 4 days
