December 2024 - Devel - libvirt List Archives

[PATCH 00/20] qemu: support mapped-ram+directio+mulitfd
by Jim Fehlig 15 Jan '25

15 Jan '25

This series is essentially V1 of a prior RFC [1] to support QEMU's mapped-ram stream format [2] and migration capability. Along with supporting mapped-ram, it implements a design approach we discussed for supporting parallel save/restore [3]. In summary, the approach is 1. Add mapped-ram migration capability 2. Steal an element from save header 'unused' for a 'features' variable and bump save version to 3. 3. Add /etc/libvirt/qemu.conf knob for the save format version, defaulting to latest v3 4. Use v3 (aka mapped-ram) by default 5. Use mapped-ram with BYPASS_CACHE for v3, old approach for v2 6. include: Define constants for parallel save/restore 7. qemu: Add support for parallel save. Implies mapped-ram, reject if v2 8. qemu: Add support for parallel restore. Implies mapped-ram. Reject if v2 9. tools: add parallel parameter to virsh save command 10. tools: add parallel parameter to virsh restore command With this series, saving and restoring using mapped-ram is enabled by default if the underlying QEMU advertises the mapped-ram migration capability. It can be disabled by changing the 'save_image_version' setting in qemu.conf. To use mapped-ram with QEMU: - The 'mapped-ram' migration capability must be set to true - The 'multifd' migration capability must be set to true and the 'multifd-channels' migration parameter must set to a value >= 1 - QEMU must be provided an fdset containing the migration fd(s) - The 'migrate' qmp command is invoked with a URI referencing the fdset and an offset where to start reading or writing the data stream, e.g. {"execute":"migrate", "arguments":{"detach":true,"resume":false, "uri":"file:/dev/fdset/0,offset=0x11921"}} The mapped-ram stream, in conjunction with direct IO and multifd, can significantly improve the time required to save VM memory state. The following tables compare mapped-ram with the existing, sequential save stream. In all cases, the save and restore operations are to/from a block device comprised of two NVMe disks in RAID0 configuration with xfs (~8600MiB/s). The values in the 'save time' and 'restore time' columns were scraped from the 'real' time reported by time(1). The 'Size' and 'Blocks' columns were provided by the corresponding outputs of stat(1). VM: 32G RAM, 1 vcpu, idle (shortly after boot) | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+-------- legacy | 6.193s | 4.399s | 985744812 | 1925288 -----------------------+---------+---------+--------------+-------- mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472 -----------------------+---------+---------+--------------+-------- legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | | | | + multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312 ------------------------------------------------------------------- VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+--------- legacy | 25.800s | 14.332s | 33154309983 | 64754512 -----------------------+---------+---------+--------------+--------- mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160 -----------------------+---------+---------+--------------+--------- legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520 -----------------------+---------+---------+--------------+--------- mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040 -----------------------+-------- +---------+--------------+--------- mapped-ram + direct IO | | | | + multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776 -------------------------------------------------------------------- As can be seen from the tables, one caveat of mapped-ram is the logical file size of a saved image is basically equivalent to the VM memory size. Note however that mapped-ram typically uses fewer blocks on disk. Support for mapped-ram+direct-io only recently landed in upstream QEMU and will first appear in the 9.1 release, which may complicate merging support in libvirt. Specifically, I'm not sure how to detect if the combination is supported by QEMU. Suggestions welcomed. Similar to the RFC, V1 ignores compression. libvirt currently supports compression by connecting the output of QEMU's save stream to the specified compression program via a pipe. This approach is incompatible with mapped-ram since the fd provided to QEMU must be seekable. In general, we can consider mapped-ram and compression incompatible and document they cannot be used together. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/EF6… [2] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/map… [3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K4B… Claudio Fontana (2): include: Define constants for parallel save/restore tools: add parallel parameter to virsh restore command Jim Fehlig (17): lib: virDomainSaveParams: Ensure absolute save path qemu_fd: Add function to retrieve fdset ID qemu: Add function to check capability in migration params qemu: Add function to get bool value from migration params qemu: Add mapped-ram migration capability qemu: Add function to get migration params for save qemu: QEMU_SAVE_VERSION: Bump to version 3 qemu: conf: Add setting for save image version qemu: Add helper function for creating save image fd qemu: Add support for mapped-ram on save qemu: Decompose qemuSaveImageOpen qemu: Move creation of qemuProcessIncomingDef struct qemu: Apply migration parameters in qemuMigrationDstRun qemu: Add support for mapped-ram on restore qemu: Support O_DIRECT with mapped-ram on save qemu: Support O_DIRECT with mapped-ram on restore qemu: Add support for parallel save and restore Li Zhang (1): tools: add parallel parameter to virsh save command docs/manpages/virsh.rst | 9 +- include/libvirt/libvirt-domain.h | 13 ++ src/libvirt-domain.c | 52 +++++-- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 6 + src/qemu/qemu_conf.c | 16 +++ src/qemu/qemu_conf.h | 5 + src/qemu/qemu_driver.c | 104 +++++++++----- src/qemu/qemu_fd.c | 18 +++ src/qemu/qemu_fd.h | 3 + src/qemu/qemu_migration.c | 192 +++++++++++++++++-------- src/qemu/qemu_migration.h | 9 +- src/qemu/qemu_migration_params.c | 86 ++++++++++++ src/qemu/qemu_migration_params.h | 17 +++ src/qemu/qemu_monitor.c | 39 ++++++ src/qemu/qemu_monitor.h | 5 + src/qemu/qemu_process.c | 120 +++++++++++----- src/qemu/qemu_process.h | 19 ++- src/qemu/qemu_saveimage.c | 216 ++++++++++++++++++++--------- src/qemu/qemu_saveimage.h | 35 +++-- src/qemu/qemu_snapshot.c | 26 ++-- src/qemu/test_libvirtd_qemu.aug.in | 1 + tools/virsh-domain.c | 79 +++++++++-- 23 files changed, 827 insertions(+), 244 deletions(-) -- 2.35.3

4 47

[PATCH 0/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno 10 Jan '25

10 Jan '25

Hi, all. - This patch adds Arm CCA support to qemu driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. - We are not yet at the stage where we can merge this patch as host linux/qemu suppor is no yet merged, but I would like to receive reviews and comments on the overall direction. [summary] - At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. - capability info uses qemu QMP to query qemu options. The option that exists now is for selecting a hash algorithm. [Capability example] - Execution results of 'virsh domcapability" on qemu <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] - To obtain capability info, it is necessary to support the qemu QMP command, which qemu does not yet support. Therefore, I put a hack in the code at hand and only confirmed the communication. Also, I think we should check whether CPUFW supports CCA or not in qemu_firmware.c, but it is not yet implemented. - Verified that the CCA VM can be started from virsh create command. [software version] - I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… - The Qemu used was based on Linaro's qemu(9.1.91). https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/v3?ref_type=heads Signed-off-by: Akio Kakuno <fj3333bs(a)fujitsu.com> Best Regards. Akio Kakuno (1): RFC: Add Arm CCA support for getting capability information and running Realm VM docs/formatdomain.rst | 28 ++++++ docs/formatdomaincaps.rst | 26 ++++- src/conf/domain_capabilities.c | 41 ++++++++ src/conf/domain_capabilities.h | 12 +++ src/conf/domain_conf.c | 13 +++ src/conf/domain_conf.h | 7 ++ src/conf/schemas/domaincaps.rng | 14 +++ src/conf/schemas/domaincommon.rng | 14 +++ src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 156 ++++++++++++++++++++++++++++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 32 ++++++ src/qemu/qemu_driver.c | 2 + src/qemu/qemu_monitor.c | 10 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 104 ++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 7 ++ 22 files changed, 487 insertions(+), 1 deletion(-) -- 2.34.1

3 3

[PATCH] spec: Enable ch driver
by Praveen K Paladugu 08 Jan '25

08 Jan '25

Enabling building and packaging ch driver in the spec file. Signed-off-by: Praveen K Paladugu <praveenkpaladugu(a)gmail.com> --- libvirt.spec.in | 51 ++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 3 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 3d5164b534..303d7cb34a 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -35,6 +35,7 @@ %define with_lxc 0%{!?_without_lxc:1} %define with_libxl 0%{!?_without_libxl:1} %define with_vbox 0%{!?_without_vbox:1} +%define with_ch 0%{!?_without_ch:1} %ifarch %{arches_qemu_kvm} %define with_qemu_kvm %{with_qemu} @@ -1026,6 +1027,20 @@ Server side daemon and driver required to manage the virtualization capabilities of VirtualBox %endif + %if %{with_ch} +%package daemon-driver-ch +Summary: Cloud-Hypervisor driver plugin for libvirtd daemon +Requires: libvirt-daemon-common = %{version}-%{release} +Requires: libvirt-daemon-log = %{version}-%{release} +Requires: libvirt-libs = %{version}-%{release} + +%description daemon-driver-ch +The ch driver plugin for the libvirtd daemon, providing +an implementation of the hypervisor driver APIs by +Cloud-Hypervisor + %endif + + %package client Summary: Client side utilities of the libvirt library Requires: libvirt-libs = %{version}-%{release} @@ -1188,9 +1203,15 @@ exit 1 %endif %if %{with_esx} - %define arg_esx -Ddriver_esx=enabled -Dcurl=enabled + %define arg_esx -Ddriver_esx=enabled +%else + %define arg_esx -Ddriver_esx=disabled +%endif + +%if %{with_esx} || %{with_ch} + %define arg_curl -Dcurl=enabled %else - %define arg_esx -Ddriver_esx=disabled -Dcurl=disabled + %define arg_curl -Dcurl=disabled %endif %if %{with_hyperv} @@ -1205,6 +1226,12 @@ exit 1 %define arg_vmware -Ddriver_vmware=disabled %endif +%if %{with_ch} + %define arg_ch -Ddriver_ch=enabled +%else + %define arg_ch -Ddriver_ch=disabled +%endif + %if %{with_storage_rbd} %define arg_storage_rbd -Dstorage_rbd=enabled %else @@ -1335,11 +1362,12 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/libvirt.spec) -Ddriver_remote=enabled \ -Ddriver_test=enabled \ %{?arg_esx} \ + %{?arg_curl} \ %{?arg_hyperv} \ %{?arg_vmware} \ + %{?arg_ch} \ -Ddriver_vz=disabled \ -Ddriver_bhyve=disabled \ - -Ddriver_ch=disabled \ %{?arg_remote_mode} \ -Ddriver_interface=enabled \ -Ddriver_network=enabled \ @@ -1541,6 +1569,10 @@ rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.libxl rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_libxl.aug rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_libxl.aug %endif + %if ! %{with_ch} +rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_ch.aug +rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_ch.aug + %endif # Copied into libvirt-docs subpackage eventually mv $RPM_BUILD_ROOT%{_datadir}/doc/libvirt libvirt-docs @@ -2405,6 +2437,19 @@ exit 0 %attr(0755, root, root) %{_libexecdir}/libvirt_sanlock_helper %endif + %if %{with_ch} +%files daemon-driver-ch +%attr(0755, root, root) %{_sbindir}/virtchd +%config(noreplace) %{_sysconfdir}/libvirt/virtchd.conf +%{_datadir}/augeas/lenses/virtchd.aug +%{_datadir}/augeas/lenses/tests/test_virtchd.aug +%{_unitdir}/virtchd-admin.socket +%{_unitdir}/virtchd-ro.socket +%{_unitdir}/virtchd.service +%{_unitdir}/virtchd.socket +%{_libdir}/libvirt/connection-driver/libvirt_driver_ch.so + %endif + %files client %{_mandir}/man1/virsh.1* %{_mandir}/man1/virt-xml-validate.1* -- 2.47.0

2 2

[PATCH] qemu: allow migration of guest with mdev vGPU to VF vGPU
by Laine Stump 08 Jan '25

08 Jan '25

GPU vendors are moving away from using mdev to create virtual GPUs towards using SRIOV VFs that are vGPUs. In both cases, once created the vGPUs are assigned to guests via <hostdev> (i.e. VFIO device assignment), and inside the guest the devices look identical, but mdev vGPUs are located by QEMU/VFIO using a uuid, while VF vGPUs are located with a PCI address. So although we generally require the device on the source host to exactly match the device on the destination host, in the case of mdev-created vGPU vs. VF vGPU migration *can* potentially work, except that libvirt has a hard-coded check that prevents us from even trying. This patch loosens up that check so that we will allow attempts to migrate a guest from a source host that has mdev-created vGPUs to a destination host that has VF vGPUs (and vice versa). The expectation is that if this doesn't actually work then QEMU will fail and generate an error that we can report. Based-on-patch-by: Zhiyi Guo <zhguo(a)redhat.com> Signed-off-by: Laine Stump <laine(a)redhat.com> --- Zhiyi's original patch removed the check for subsys type completely, and this worked. My modified patch keeps the check in place, but allows it to pass if the src type is pci and dst is mdev, or vice versa. src/conf/domain_conf.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 4ad8289b89..9d5fda0469 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -20647,13 +20647,27 @@ virDomainHostdevDefCheckABIStability(virDomainHostdevDef *src, return false; } - if (src->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS && - src->source.subsys.type != dst->source.subsys.type) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Target host device subsystem %1$s does not match source %2$s"), - virDomainHostdevSubsysTypeToString(dst->source.subsys.type), - virDomainHostdevSubsysTypeToString(src->source.subsys.type)); - return false; + if (src->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) { + virDomainHostdevSubsysType srcType = src->source.subsys.type; + virDomainHostdevSubsysType dstType = dst->source.subsys.type; + + /* If the source and destination subsys types aren't the same, + * then migration can't be supported, *except* that it might + * be supported to migrate from subsys type 'pci' to 'mdev' + * and vice versa. (libvirt can't know for certain whether or + * not it will actually work, so we have to just allow it and + * count on QEMU to provide us with an error if it fails) + */ + + if (srcType != dstType + && ((srcType != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI && srcType != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV) + || (dstType != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI && dstType != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Target host device subsystem type %1$s is not compatible with source subsystem type %2$s"), + virDomainHostdevSubsysTypeToString(dstType), + virDomainHostdevSubsysTypeToString(srcType)); + return false; + } } if (!virDomainDeviceInfoCheckABIStability(src->info, dst->info)) -- 2.47.1

2 2

[PATCH] qemu: Add audit entries for suspend and resume
by Jim Fehlig 07 Jan '25

07 Jan '25

We recently received a request from certification auditors to provide audit entries for suspend and resume. This small patch uses the existing virtDomainAudit{Start,Stop} functions with new reasons "suspended" and "resumed". Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- For suspend, I initially wrote the following virDomainAuditStart(vm, virDomainPausedReasonTypeToString(reason), true); but I'm not sure it makes sense in resume, where we have reasons such as VIR_DOMAIN_CRASHED_PANICKED. For symmetry, it seemed best to go with "suspended" and "resumed". src/qemu/qemu_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f1a633fdd3..c670bb681e 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1682,6 +1682,7 @@ static int qemuDomainSuspend(virDomainPtr dom) goto endjob; } qemuDomainSaveStatus(vm); + virDomainAuditStart(vm, "suspended", true); ret = 0; endjob: @@ -1738,6 +1739,7 @@ static int qemuDomainResume(virDomainPtr dom) } } qemuDomainSaveStatus(vm); + virDomainAuditStop(vm, "resumed"); ret = 0; endjob: -- 2.43.0

3 4

[PATCH v2 0/4] fix AppArmor policy restore for runtime rules
by Georgia Garcia 07 Jan '25

07 Jan '25

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/security_apparmor.c | 83 +++++----- src/security/virt-aa-helper.c | 145 +++++++++--------- 4 files changed, 120 insertions(+), 120 deletions(-) -- 2.34.1

4 11

[PATCH v2 1/3] Revert "qemu: explicit swtpm state locking"
by marcandre.lureau＠redhat.com 06 Jan '25

06 Jan '25

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> This reverts commit bb5e26749fe5b5856a3541be2cbe147701e6e121. swtpm-setup doesn't have "tpmstate-lock", only swtpm. Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- src/qemu/qemu_tpm.c | 11 ++--------- src/util/virtpm.c | 1 - src/util/virtpm.h | 1 - tests/testutilsqemu.c | 1 - 4 files changed, 2 insertions(+), 12 deletions(-) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index f5e0184e54..476e3dd224 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -344,23 +344,16 @@ static char * qemuTPMGetSwtpmSetupStateArg(const virDomainTPMSourceType source_type, const char *source_path) { - const char *lock = ",lock"; - - if (!virTPMSwtpmSetupCapsGet(VIR_TPM_SWTPM_SETUP_FEATURE_TPMSTATE_OPT_LOCK)) { - VIR_WARN("This swtpm version doesn't support explicit locking"); - lock = ""; - } - switch (source_type) { case VIR_DOMAIN_TPM_SOURCE_TYPE_FILE: /* the file:// prefix is supported since swtpm_setup 0.7.0 */ /* assume the capability check for swtpm is redundant. */ - return g_strdup_printf("file://%s%s", source_path, lock); + return g_strdup_printf("file://%s", source_path); case VIR_DOMAIN_TPM_SOURCE_TYPE_DIR: case VIR_DOMAIN_TPM_SOURCE_TYPE_DEFAULT: case VIR_DOMAIN_TPM_SOURCE_TYPE_LAST: default: - return g_strdup_printf("%s%s", source_path, lock); + return g_strdup_printf("%s", source_path); } } diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 4016ad8fc4..f90839debe 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -53,7 +53,6 @@ VIR_ENUM_IMPL(virTPMSwtpmSetupFeature, "cmdarg-reconfigure-pcr-banks", "tpm-1.2", "tpm-2.0", - "tpmstate-opt-lock", "cmdarg-profile", ); diff --git a/src/util/virtpm.h b/src/util/virtpm.h index 03fb92629a..4119a903e5 100644 --- a/src/util/virtpm.h +++ b/src/util/virtpm.h @@ -45,7 +45,6 @@ typedef enum { VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_RECONFIGURE_PCR_BANKS, VIR_TPM_SWTPM_SETUP_FEATURE_TPM_1_2, VIR_TPM_SWTPM_SETUP_FEATURE_TPM_2_0, - VIR_TPM_SWTPM_SETUP_FEATURE_TPMSTATE_OPT_LOCK, VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PROFILE, VIR_TPM_SWTPM_SETUP_FEATURE_LAST diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c index 5caccbc6b4..abc425b9b7 100644 --- a/tests/testutilsqemu.c +++ b/tests/testutilsqemu.c @@ -71,7 +71,6 @@ virTPMSwtpmSetupCapsGet(virTPMSwtpmSetupFeature cap) case VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES: case VIR_TPM_SWTPM_SETUP_FEATURE_TPM12_NOT_NEED_ROOT: case VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_RECONFIGURE_PCR_BANKS: - case VIR_TPM_SWTPM_SETUP_FEATURE_TPMSTATE_OPT_LOCK: case VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PROFILE: case VIR_TPM_SWTPM_SETUP_FEATURE_LAST: break; -- 2.47.0

4 6

[PATCH] apparmor: Allow running loongarch64 VMs on Debian 12
by Xianglai Li 06 Jan '25

06 Jan '25

Allows to load firmware in the qemu-efi-loongarch64 directory Allows the binary qemu-system-loongarch64 to be run This makes it impossible to run loongarch64 VMs when AppArmor is enabled Signed-off-by: Xianglai Li <lixianglai(a)loongson.cn> --- src/security/apparmor/libvirt-qemu.in | 1 + src/security/virt-aa-helper.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/security/apparmor/libvirt-qemu.in b/src/security/apparmor/libvirt-qemu.in index 694da26dea..c63077574e 100644 --- a/src/security/apparmor/libvirt-qemu.in +++ b/src/security/apparmor/libvirt-qemu.in @@ -144,6 +144,7 @@ /usr/bin/qemu-system-hppa rmix, /usr/bin/qemu-system-i386 rmix, /usr/bin/qemu-system-lm32 rmix, + /usr/bin/qemu-system-loongarch64 rmix, /usr/bin/qemu-system-m68k rmix, /usr/bin/qemu-system-microblaze rmix, /usr/bin/qemu-system-microblazeel rmix, diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 1cf9d7ad3d..94a28bf331 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -481,6 +481,7 @@ valid_path(const char *path, const bool readonly) "/usr/share/AAVMF/", "/usr/share/qemu-efi/", /* for AAVMF images */ "/usr/share/qemu-efi-aarch64/", + "/usr/share/qemu-efi-loongarch64/", "/usr/share/qemu-efi-riscv64/", "/usr/share/qemu/", /* SUSE path for OVMF and AAVMF images */ "/usr/lib/u-boot/", -- 2.39.1

3 5

[PATCH] hyperv: Introduce and export 'facility' variable.
by Michal Privoznik 06 Jan '25

06 Jan '25

In its upstream commit [1] openwsman dropped 'facility' variable which is documented as: * all processes that use the libu must define a "facility" variable somewhere * to satisfy this external linkage reference. * * Such variable will be used as the syslog(3) facility argument. Well, prior to that commit, openwsman itself declared the variable (and set it to LOG_DAEMON). Now it's up to us. Yeah, the variable naming is terrible and also I we are not using libu directly, but apparently libwsman.so requires it anyway: $ objdump -T /usr/lib64/libwsman.so | grep facility 0000000000000000 D *UND* 0000000000000000 Base facility 1: https://github.com/Openwsman/openwsman/commit/d72c51f21b9c85a773b7955ac587d… Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/hyperv/hyperv_wmi.c | 3 +++ src/libvirt_hyperv.syms | 11 +++++++++++ src/meson.build | 6 ++++++ 3 files changed, 20 insertions(+) create mode 100644 src/libvirt_hyperv.syms diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c index 0b82f1f131..040bcfec11 100644 --- a/src/hyperv/hyperv_wmi.c +++ b/src/hyperv/hyperv_wmi.c @@ -28,6 +28,7 @@ #include <wsman-soap.h> #include <wsman-xml.h> #include <wsman-xml-binding.h> +#include <u/syslog.h> #include "internal.h" #include "virerror.h" @@ -47,6 +48,8 @@ VIR_LOG_INIT("hyperv.hyperv_wmi"); +int facility = LOG_DAEMON; + int hypervGetWmiClassList(hypervPrivate *priv, hypervWmiClassInfo *wmiInfo, virBuffer *query, hypervObject **wmiClass) diff --git a/src/libvirt_hyperv.syms b/src/libvirt_hyperv.syms new file mode 100644 index 0000000000..60e98db473 --- /dev/null +++ b/src/libvirt_hyperv.syms @@ -0,0 +1,11 @@ +# +# HyperV-specific symbols +# + +# hyperv/hyperv_wmi.c +facility; + +# Let emacs know we want case-insensitive sorting +# Local Variables: +# sort-fold-case: t +# End: diff --git a/src/meson.build b/src/meson.build index b53ea2a71f..cce89fac27 100644 --- a/src/meson.build +++ b/src/meson.build @@ -125,6 +125,12 @@ else sym_files += 'libvirt_libssh2.syms' endif +if conf.has('WITH_HYPERV') + used_sym_files += 'libvirt_hyperv.syms' +else + sym_files += 'libvirt_hyperv.syms' +endif + # variables filled by subdirectories libvirt_libs = [] -- 2.45.2

2 1

[PATCH 0/2] po: handle translatin of polkit policy file strings
by Daniel P. Berrangé 03 Jan '25

03 Jan '25

There was a proposal https://gitlab.com/libvirt/libvirt/-/merge_requests/387 to add translations for the polkit files. In reviewing this we came to the conclusion the approach was undesirable. After getting misled by a Debian/Ubuntu specific downstream only patch to polkit which auto-translated polkit files at runtime, this implements the manual approach of merging translations into the polkit files at build time. Daniel P. Berrangé (2): po: add its rules for translating polkit file strings remote: apply translations to polkit files meson.build | 5 +++++ po/POTFILES | 2 ++ po/its/polkit.its | 8 ++++++++ po/its/polkit.loc | 6 ++++++ po/meson.build | 3 +-- src/access/meson.build | 18 ++++++++++++++---- .../{libvirtd.policy => libvirtd.policy.in} | 0 src/remote/meson.build | 13 ++++++++----- 8 files changed, 44 insertions(+), 11 deletions(-) create mode 100644 po/its/polkit.its create mode 100644 po/its/polkit.loc rename src/remote/{libvirtd.policy => libvirtd.policy.in} (100%) -- 2.46.0

2 4