June 2025 - Devel - libvirt List Archives

[PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
by Hector Cao 18 Jun '25

18 Jun '25

Several Intel CPU models with TSX technology (HLE & RTM features) are affected by the vulnerability TAA[1]. One of the mitigation methods for TAA is to disable TSX support on the host system. For that purpose, in 2021, Intel published a microcode update to disable TSX. Linux kernel also disables TSX globally by default. Even though TSX can be activated via the kernel command line (tsx=on), many Linux distributions stick with this default behavior and have TSX disabled. This makes existing CPU models that have HLE and RTM enabled not correctly detected by libvirt. This commit adds 2 remaining -noTSX models: - SapphireRapids-noTSX - GraniteRapids-noTSX Hopefully, this is the last effort on adding noTSX variants since Granite Rapids should be the last CPU model to have the TSX feature and is consequently affected by TAA. Indeed, SierraForest does not have RTM and HLE enabled. References: [1] TAA, TSX asynchronous Abort: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.… --- src/cpu_map/index.xml | 2 + src/cpu_map/meson.build | 2 + src/cpu_map/x86_GraniteRapids-noTSX.xml | 197 +++++++++++++++++++++++ src/cpu_map/x86_SapphireRapids-noTSX.xml | 190 ++++++++++++++++++++++ 4 files changed, 391 insertions(+) create mode 100644 src/cpu_map/x86_GraniteRapids-noTSX.xml create mode 100644 src/cpu_map/x86_SapphireRapids-noTSX.xml diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 87db338cee..03a2c73ba5 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -116,10 +116,12 @@ <include filename='x86_Snowridge-v3.xml'/> <include filename='x86_Snowridge-v4.xml'/> <include filename='x86_SapphireRapids.xml'/> + <include filename='x86_SapphireRapids-noTSX.xml'/> <include filename='x86_SapphireRapids-v1.xml'/> <include filename='x86_SapphireRapids-v2.xml'/> <include filename='x86_SapphireRapids-v3.xml'/> <include filename='x86_GraniteRapids.xml'/> + <include filename='x86_GraniteRapids-noTSX.xml'/> <include filename='x86_GraniteRapids-v1.xml'/> <include filename='x86_GraniteRapids-v2.xml'/> <include filename='x86_SierraForest.xml'/> diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index dee8441a13..414cad7352 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -80,6 +80,7 @@ cpumap_data = [ 'x86_features.xml', 'x86_GraniteRapids-v1.xml', 'x86_GraniteRapids-v2.xml', + 'x86_GraniteRapids-noTSX.xml', 'x86_GraniteRapids.xml', 'x86_Haswell-IBRS.xml', 'x86_Haswell-noTSX-IBRS.xml', @@ -148,6 +149,7 @@ cpumap_data = [ 'x86_SapphireRapids-v1.xml', 'x86_SapphireRapids-v2.xml', 'x86_SapphireRapids-v3.xml', + 'x86_SapphireRapids-noTSX.xml', 'x86_SapphireRapids.xml', 'x86_SierraForest-v1.xml', 'x86_SierraForest.xml', diff --git a/src/cpu_map/x86_GraniteRapids-noTSX.xml b/src/cpu_map/x86_GraniteRapids-noTSX.xml new file mode 100644 index 0000000000..085b012f83 --- /dev/null +++ b/src/cpu_map/x86_GraniteRapids-noTSX.xml @@ -0,0 +1,197 @@ +<cpus> + <model name='GraniteRapids-noTSX'> + <check partial='compat'/> + <decode host='on' guest='off'/> + <signature family='6' model='173'/> + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='amx-bf16'/> + <feature name='amx-fp16'/> + <feature name='amx-int8'/> + <feature name='amx-tile'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='arch-capabilities'/> + <feature name='avx'/> + <feature name='avx-vnni'/> + <feature name='avx2'/> + <feature name='avx512-bf16'/> + <feature name='avx512-fp16'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512ifma'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='bus-lock-detect'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fbsdp-no'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fsrc'/> + <feature name='fsrm'/> + <feature name='fsrs'/> + <feature name='fxsr'/> + <feature name='fzrm'/> + <feature name='gfni'/> + <feature name='ibrs-all'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mcdt-no'/> + <feature name='mce'/> + <feature name='mds-no'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pbrsb-no'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='prefetchiti'/> + <feature name='pschange-mc-no'/> + <feature name='psdp-no'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdctl-no'/> + <feature name='rdpid'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='sbdr-ssdp-no'/> + <feature name='sep'/> + <feature name='serialize'/> + <feature name='sha-ni'/> + <feature name='skip-l1dfl-vmentry'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='taa-no'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='tsx-ldtrk'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vmx-activity-hlt'/> + <feature name='vmx-apicv-register'/> + <feature name='vmx-apicv-vid'/> + <feature name='vmx-apicv-x2apic'/> + <feature name='vmx-apicv-xapic'/> + <feature name='vmx-cr3-load-noexit'/> + <feature name='vmx-cr3-store-noexit'/> + <feature name='vmx-cr8-load-exit'/> + <feature name='vmx-cr8-store-exit'/> + <feature name='vmx-desc-exit'/> + <feature name='vmx-entry-ia32e-mode'/> + <feature name='vmx-entry-load-efer'/> + <feature name='vmx-entry-load-pat'/> + <feature name='vmx-entry-load-perf-global-ctrl'/> + <feature name='vmx-entry-noload-debugctl'/> + <feature name='vmx-ept'/> + <feature name='vmx-ept-1gb'/> + <feature name='vmx-ept-2mb'/> + <feature name='vmx-ept-execonly'/> + <feature name='vmx-eptad'/> + <feature name='vmx-eptp-switching'/> + <feature name='vmx-exit-ack-intr'/> + <feature name='vmx-exit-load-efer'/> + <feature name='vmx-exit-load-pat'/> + <feature name='vmx-exit-load-perf-global-ctrl'/> + <feature name='vmx-exit-nosave-debugctl'/> + <feature name='vmx-exit-save-efer'/> + <feature name='vmx-exit-save-pat'/> + <feature name='vmx-exit-save-preemption-timer'/> + <feature name='vmx-flexpriority'/> + <feature name='vmx-hlt-exit'/> + <feature name='vmx-ins-outs'/> + <feature name='vmx-intr-exit'/> + <feature name='vmx-invept'/> + <feature name='vmx-invept-all-context'/> + <feature name='vmx-invept-single-context'/> + <feature name='vmx-invlpg-exit'/> + <feature name='vmx-invpcid-exit'/> + <feature name='vmx-invvpid'/> + <feature name='vmx-invvpid-all-context'/> + <feature name='vmx-invvpid-single-addr'/> + <feature name='vmx-invvpid-single-context-noglobals'/> + <feature name='vmx-io-bitmap'/> + <feature name='vmx-io-exit'/> + <feature name='vmx-monitor-exit'/> + <feature name='vmx-movdr-exit'/> + <feature name='vmx-msr-bitmap'/> + <feature name='vmx-mtf'/> + <feature name='vmx-mwait-exit'/> + <feature name='vmx-nmi-exit'/> + <feature name='vmx-page-walk-4'/> + <feature name='vmx-page-walk-5'/> + <feature name='vmx-pause-exit'/> + <feature name='vmx-pml'/> + <feature name='vmx-posted-intr'/> + <feature name='vmx-preemption-timer'/> + <feature name='vmx-rdpmc-exit'/> + <feature name='vmx-rdrand-exit'/> + <feature name='vmx-rdseed-exit'/> + <feature name='vmx-rdtsc-exit'/> + <feature name='vmx-rdtscp-exit'/> + <feature name='vmx-secondary-ctls'/> + <feature name='vmx-shadow-vmcs'/> + <feature name='vmx-store-lma'/> + <feature name='vmx-true-ctls'/> + <feature name='vmx-tsc-offset'/> + <feature name='vmx-unrestricted-guest'/> + <feature name='vmx-vintr-pending'/> + <feature name='vmx-vmfunc'/> + <feature name='vmx-vmwrite-vmexit-fields'/> + <feature name='vmx-vnmi'/> + <feature name='vmx-vnmi-pending'/> + <feature name='vmx-vpid'/> + <feature name='vmx-wbinvd-exit'/> + <feature name='vmx-xsaves'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xfd'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + <feature name='xsaves'/> + </model> +</cpus> diff --git a/src/cpu_map/x86_SapphireRapids-noTSX.xml b/src/cpu_map/x86_SapphireRapids-noTSX.xml new file mode 100644 index 0000000000..de56826741 --- /dev/null +++ b/src/cpu_map/x86_SapphireRapids-noTSX.xml @@ -0,0 +1,190 @@ +<cpus> + <model name='SapphireRapids-noTSX'> + <check partial='compat'/> + <decode host='on' guest='off'/> + <signature family='6' model='143'/> + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='amx-bf16'/> + <feature name='amx-int8'/> + <feature name='amx-tile'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='arch-capabilities'/> + <feature name='avx'/> + <feature name='avx-vnni'/> + <feature name='avx2'/> + <feature name='avx512-bf16'/> + <feature name='avx512-fp16'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512ifma'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='bus-lock-detect'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fsrc'/> + <feature name='fsrm'/> + <feature name='fsrs'/> + <feature name='fxsr'/> + <feature name='fzrm'/> + <feature name='gfni'/> + <feature name='ibrs-all'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mce'/> + <feature name='mds-no'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='pschange-mc-no'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdctl-no'/> + <feature name='rdpid'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='sep'/> + <feature name='serialize'/> + <feature name='sha-ni'/> + <feature name='skip-l1dfl-vmentry'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='taa-no'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='tsx-ldtrk'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vmx-activity-hlt' added='yes'/> + <feature name='vmx-apicv-register' added='yes'/> + <feature name='vmx-apicv-vid' added='yes'/> + <feature name='vmx-apicv-x2apic' added='yes'/> + <feature name='vmx-apicv-xapic' added='yes'/> + <feature name='vmx-cr3-load-noexit' added='yes'/> + <feature name='vmx-cr3-store-noexit' added='yes'/> + <feature name='vmx-cr8-load-exit' added='yes'/> + <feature name='vmx-cr8-store-exit' added='yes'/> + <feature name='vmx-desc-exit' added='yes'/> + <feature name='vmx-entry-ia32e-mode' added='yes'/> + <feature name='vmx-entry-load-efer' added='yes'/> + <feature name='vmx-entry-load-pat' added='yes'/> + <feature name='vmx-entry-load-perf-global-ctrl' added='yes'/> + <feature name='vmx-entry-noload-debugctl' added='yes'/> + <feature name='vmx-ept' added='yes'/> + <feature name='vmx-ept-1gb' added='yes'/> + <feature name='vmx-ept-2mb' added='yes'/> + <feature name='vmx-ept-execonly' added='yes'/> + <feature name='vmx-eptad' added='yes'/> + <feature name='vmx-eptp-switching' added='yes'/> + <feature name='vmx-exit-ack-intr' added='yes'/> + <feature name='vmx-exit-load-efer' added='yes'/> + <feature name='vmx-exit-load-pat' added='yes'/> + <feature name='vmx-exit-load-perf-global-ctrl' added='yes'/> + <feature name='vmx-exit-nosave-debugctl' added='yes'/> + <feature name='vmx-exit-save-efer' added='yes'/> + <feature name='vmx-exit-save-pat' added='yes'/> + <feature name='vmx-exit-save-preemption-timer' added='yes'/> + <feature name='vmx-flexpriority' added='yes'/> + <feature name='vmx-hlt-exit' added='yes'/> + <feature name='vmx-ins-outs' added='yes'/> + <feature name='vmx-intr-exit' added='yes'/> + <feature name='vmx-invept' added='yes'/> + <feature name='vmx-invept-all-context' added='yes'/> + <feature name='vmx-invept-single-context' added='yes'/> + <feature name='vmx-invlpg-exit' added='yes'/> + <feature name='vmx-invpcid-exit' added='yes'/> + <feature name='vmx-invvpid' added='yes'/> + <feature name='vmx-invvpid-all-context' added='yes'/> + <feature name='vmx-invvpid-single-addr' added='yes'/> + <feature name='vmx-invvpid-single-context-noglobals' added='yes'/> + <feature name='vmx-io-bitmap' added='yes'/> + <feature name='vmx-io-exit' added='yes'/> + <feature name='vmx-monitor-exit' added='yes'/> + <feature name='vmx-movdr-exit' added='yes'/> + <feature name='vmx-msr-bitmap' added='yes'/> + <feature name='vmx-mtf' added='yes'/> + <feature name='vmx-mwait-exit' added='yes'/> + <feature name='vmx-nmi-exit' added='yes'/> + <feature name='vmx-page-walk-4' added='yes'/> + <feature name='vmx-page-walk-5' added='yes'/> + <feature name='vmx-pause-exit' added='yes'/> + <feature name='vmx-pml' added='yes'/> + <feature name='vmx-posted-intr' added='yes'/> + <feature name='vmx-preemption-timer' added='yes'/> + <feature name='vmx-rdpmc-exit' added='yes'/> + <feature name='vmx-rdrand-exit' added='yes'/> + <feature name='vmx-rdseed-exit' added='yes'/> + <feature name='vmx-rdtsc-exit' added='yes'/> + <feature name='vmx-rdtscp-exit' added='yes'/> + <feature name='vmx-secondary-ctls' added='yes'/> + <feature name='vmx-shadow-vmcs' added='yes'/> + <feature name='vmx-store-lma' added='yes'/> + <feature name='vmx-true-ctls' added='yes'/> + <feature name='vmx-tsc-offset' added='yes'/> + <feature name='vmx-unrestricted-guest' added='yes'/> + <feature name='vmx-vintr-pending' added='yes'/> + <feature name='vmx-vmfunc' added='yes'/> + <feature name='vmx-vmwrite-vmexit-fields' added='yes'/> + <feature name='vmx-vnmi' added='yes'/> + <feature name='vmx-vnmi-pending' added='yes'/> + <feature name='vmx-vpid' added='yes'/> + <feature name='vmx-wbinvd-exit' added='yes'/> + <feature name='vmx-xsaves' added='yes'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xfd'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + <feature name='xsaves'/> + </model> +</cpus> -- 2.45.2

3 7

[PATCH] security_manager: Don't leak seclabel in virSecurityManagerGenLabel()
by Michal Privoznik 18 Jun '25

18 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> When a domain is being started, seclabels are generated for it. This is handled in virSecurityManagerGenLabel() which can either find pre-existing seclabel in domain def or generate a new one. At any rate, domainGenSecurityLabel() callback is called and if it fails then the seclabel is removed from domain definition using VIR_DELETE_ELEMENT(). While this shrinks down the seclabels array, it does not free individual item. It has to be freed manually. 80 bytes in 2 blocks are definitely lost in loss record 1,359 of 1,876 at 0x484CEF3: calloc (vg_replace_malloc.c:1675) by 0x4F19B29: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8200.5) by 0x49E4953: virSecurityLabelDefNew (virseclabel.c:59) by 0x4BDE0A4: virSecurityManagerGenLabel (security_manager.c:638) by 0xBA029B7: qemuProcessPrepareDomain (qemu_process.c:6760) by 0xBA07DF2: qemuProcessStart (qemu_process.c:8369) by 0xB93DAC0: qemuDomainObjStart (qemu_driver.c:6371) by 0xB93DE08: qemuDomainCreateWithFlags (qemu_driver.c:6420) by 0xB93DE86: qemuDomainCreate (qemu_driver.c:6438) by 0x4CECEA8: virDomainCreate (libvirt-domain.c:7142) Now, you might think this may lead to a double free, because @seclabel is freed under the 'cleanup' label (if @generated is true). But if @generated is true, then just before calling the callback there's VIR_APPEND_ELEMENT() which clears @seclabel out turning the free under 'cleanup' label into a NOP. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/security/security_manager.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/security/security_manager.c b/src/security/security_manager.c index c2460eae37..5fc4eb4872 100644 --- a/src/security/security_manager.c +++ b/src/security/security_manager.c @@ -669,9 +669,14 @@ virSecurityManagerGenLabel(virSecurityManager *mgr, VIR_APPEND_ELEMENT(vm->seclabels, vm->nseclabels, seclabel); if (sec_managers[i]->drv->domainGenSecurityLabel(sec_managers[i], vm) < 0) { + virSecurityLabelDef *tmp = vm->seclabels[vm->nseclabels - 1]; + if (VIR_DELETE_ELEMENT(vm->seclabels, - vm->nseclabels -1, vm->nseclabels) < 0) + vm->nseclabels - 1, vm->nseclabels) < 0) { vm->nseclabels--; + } + + virSecurityLabelDefFree(tmp); goto cleanup; } -- 2.49.0

3 2

Plans for 11.5.0 release (freeze on 2025-06-24)
by Jiri Denemark 18 Jun '25

18 Jun '25

We are getting close to 11.5.0 release of libvirt. To aim for the release on Tuesday 01 Jul I suggest entering the freeze on Tuesday 24 Jun and tagging RC2 on Friday 27 Jun. I hope this works for everyone. Jirka

1 0

[PATCH] virSocketAddrPrefixToNetmask: Prevent undefined behaviour on bitshifts on signed integer
by Peter Krempa 18 Jun '25

18 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Shifting bits into the sign bit is undefined behaviour in C although both gcc and clang handle it as expected. Since the value is used as unsigned convert it to unsigned int. For code readability use 'if' statement instead of a ternary. Closes: https://gitlab.com/libvirt/libvirt/-/issues/785 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virsocketaddr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/util/virsocketaddr.c b/src/util/virsocketaddr.c index a2e6701670..f53768878e 100644 --- a/src/util/virsocketaddr.c +++ b/src/util/virsocketaddr.c @@ -1144,12 +1144,14 @@ virSocketAddrPrefixToNetmask(unsigned int prefix, netmask->data.stor.ss_family = AF_UNSPEC; /* assume failure */ if (family == AF_INET) { - int ip; + unsigned int ip = 0; if (prefix > 32) return -1; - ip = prefix ? ~((1 << (32 - prefix)) - 1) : 0; + if (prefix > 0) + ip = ~((1U << (32 - prefix)) - 1); + netmask->data.inet4.sin_addr.s_addr = htonl(ip); netmask->data.stor.ss_family = AF_INET; netmask->len = sizeof(struct sockaddr_in); -- 2.49.0

2 1

[PATCH] qemu: Be more forgiving when acquiring QUERY job when formatting domain XML
by Michal Privoznik 18 Jun '25

18 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> In my previous commit of v11.0.0-rc1~115 I've made QEMU driver implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc()) acquire QERY job. See its commit message for more info. But this unfortunately broke apps witch fetch domain XML for incoming migration (like virt-manager). The reason is that for incoming migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but the mask of allowed synchronous jobs is empty (because QEMU can't talk on monitor really). This makes virDomainObjBeginJob() fail which in turn makes qemuDomainGetXMLDesc() fail too. It makes sense for qemuDomainGetXMLDesc() to acquire the job (e.g. so that it's coherent with another thread that might be in the middle of a MODIFY job). But failure to dump XML may be treated as broken daemon (e.g. virt-manager does so). Therefore, still try to acquire the QUERY job (if job mask permits it) but, do not treat failure as an error. Fixes: 6cc93bf28842526be2fd596a607ebca796b7fb2e Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2369243 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_driver.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b3b0ee66f8..9b583ad7aa 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6182,6 +6182,7 @@ static char { virQEMUDriver *driver = dom->conn->privateData; virDomainObj *vm; + bool hasJob = false; char *ret = NULL; virCheckFlags(VIR_DOMAIN_XML_COMMON_FLAGS | VIR_DOMAIN_XML_UPDATE_CPU, @@ -6193,8 +6194,10 @@ static char if (virDomainGetXMLDescEnsureACL(dom->conn, vm->def, flags) < 0) goto cleanup; - if (virDomainObjBeginJob(vm, VIR_JOB_QUERY) < 0) - goto cleanup; + if (virDomainNestedJobAllowed(vm->job, VIR_JOB_QUERY) && + virDomainObjBeginJob(vm, VIR_JOB_QUERY) >= 0) { + hasJob = true; + } qemuDomainUpdateCurrentMemorySize(vm); @@ -6210,7 +6213,8 @@ static char ret = qemuDomainFormatXML(driver, vm, flags); - virDomainObjEndJob(vm); + if (hasJob) + virDomainObjEndJob(vm); cleanup: virDomainObjEndAPI(&vm); -- 2.49.0

2 1

[PATCH 0/6] Various fixes and cleanups
by Peter Krempa 17 Jun '25

17 Jun '25

A collection of random one-off fixes for issues where the root cause was analyzed by the reporter and cleanups that I've recently accumulated. Peter Krempa (6): storage_file_probe: Use named initializer for 'struct FileTypeInfo' virQEMUCapsFindBinary: Refactor local variables virshPrintJobProgress: Don't rewrite migration status line on non-terminals storage: parthelper: Use if/else instead of ternary operator storage: disk: Properly handle partition numbers separated by 'p' tlscert: Don't force 'keyEncipherment' for ECDSA and ECDH src/qemu/qemu_capabilities.c | 9 +- src/rpc/virnettlscert.c | 33 +++-- src/storage/parthelper.c | 7 +- src/storage/storage_backend_disk.c | 9 +- src/storage_file/storage_file_probe.c | 174 ++++++++++++++++++-------- tools/virsh-domain.c | 13 +- 6 files changed, 165 insertions(+), 80 deletions(-) -- 2.49.0

4 9

Re: [PATCH v4 00/27] hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines
by Igor Mammedov 17 Jun '25

17 Jun '25

On Thu, 8 May 2025 15:35:23 +0200 Philippe Mathieu-Daudé <philmd(a)linaro.org> wrote: > Since v3: > - Addressed Thomas and Zhao review comments > - Rename fw_cfg_init_mem_[no]dma() helpers > - Remove unused CPU properties > - Remove {multi,linux}boot.bin > - Added R-b tags > > Since v2: > - Addressed Mark review comments and added his R-b tags > > The versioned 'pc' and 'q35' machines up to 2.12 been marked > as deprecated two releases ago, and are older than 6 years, > so according to our support policy we can remove them. > > This series only includes the 2.6 and 2.7 machines removal, > as it is a big enough number of LoC removed. Rest will > follow. CCing libvirt folks series removes some properties that has been used as compat knobs with 2.6/2.7 machine types that are being removed. However libvirt might still use them, please check if being removed properties are safe to remove as is | should be deprecated 1st | should be left alone from an immediate user perspective. > > Based-on: <20250506143905.4961-1-philmd(a)linaro.org> > [...]

5 4

SEO website
by nokores231＠finfave.com 16 Jun '25

16 Jun '25

SEO website brings you the best free porn in incredible quality and variety for your satisfaction. The web is very useful if you are looking for lesbian porn, Asian porn, or beautiful Indian girls. It is a website that has a lot of potentials and that you should visit to enjoy the best porn online. https://www.freebestpost.com/escorts/assortlist-com~2022_02~15

1 0

escorts services
by mahom90637＠nab4.com 16 Jun '25

16 Jun '25

The top rated escort sites allow you to contact the girl that suits your needs. That is to say, you will be able to call the prostitutes that you consider to be the most beautiful, sensual, or simply cheap. https://www.canadaescorts.ca

1 0

[PATCH v4 0/5] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 13 Jun '25

13 Jun '25

Changelog v4 - added qemu.conf option to dictate the default behavior for the deprecated_features attribute (Boris) - added qemuxmlactivetests (Boris) - snuck in missing documentation for deprecated_features in formatdomain.rst v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU *host models* migration ready from the get-go by introducing a qemu.conf option for disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. The configured behavior may be overridden by explicitly providing the attribute within the guest XML. Boris Fiuczynski (1): tests: new qemuxmlactive tests for s390x Collin Walling (4): docs: domain: document deprecated_features attribute qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: add default_cpu_deprecated_features configuration option docs/formatdomain.rst | 8 ++++ src/qemu/libvirtd_qemu.aug | 3 ++ src/qemu/qemu.conf.in | 14 ++++++ src/qemu/qemu_capabilities.c | 6 +-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_conf.c | 33 +++++++++++++ src/qemu/qemu_conf.h | 12 +++++ src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 46 +++++++++++++++---- src/qemu/test_libvirtd_qemu.aug.in | 1 + ...ated-features-none-active.s390x-latest.xml | 25 ++++++++++ ...ed-features-none-inactive.s390x-latest.xml | 25 ++++++++++ ...cated-features-off-active.s390x-latest.xml | 25 ++++++++++ ...ted-features-off-inactive.s390x-latest.xml | 25 ++++++++++ ...ecated-features-on-active.s390x-latest.xml | 25 ++++++++++ ...ated-features-on-inactive.s390x-latest.xml | 25 ++++++++++ tests/qemuxmlactivetest.c | 11 ++++- ...deprecated-features-none.s390x-latest.args | 32 +++++++++++++ ...-deprecated-features-none.s390x-latest.xml | 25 ++++++++++ .../cpu-model-deprecated-features-none.xml | 15 ++++++ ...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++ ...el-deprecated-features-on.s390x-latest.xml | 25 ++++++++++ .../cpu-model-deprecated-features-on.xml | 15 ++++++ ...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-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- tests/qemuxmlconftest.c | 2 + 30 files changed, 426 insertions(+), 22 deletions(-) create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml -- 2.47.1

1 5

[PATCH v3 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober 13 Jun '25

13 Jun '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

2 4

[PATCH 0/3] qemu: Replace usb-storage with usb-bot
by Akihiko Odaki 12 Jun '25

12 Jun '25

usb-storage is a compound device that automatically creates a USB mass storage device and a SCSI device as its backend. Unfortunately it lacks some configuration options that are usually present with a SCSI device, and cannot represent CD-ROM in particular. Replace usb-storage with usb-bot, which can be combined with a manually created SCSI device. libvirt will configure the SCSI device in a way identical with how QEMU does for usb-storage except that now it respects a configuration option to represent CD-ROM. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368 Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Akihiko Odaki (3): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT qemu: Replace usb-storage with usb-bot qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE src/qemu/qemu_alias.c | 3 +- src/qemu/qemu_capabilities.c | 19 +- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_command.c | 55 +++++- src/qemu/qemu_command.h | 5 + src/qemu/qemu_hotplug.c | 34 +++- src/qemu/qemu_validate.c | 4 +- .../qemucapabilitiesdata/caps_10.0.0_s390x.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 2 +- .../caps_10.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 2 +- .../caps_5.2.0_aarch64.replies | 174 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_ppc64.replies | 178 +++++------------- tests/qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 2 +- .../caps_5.2.0_riscv64.replies | 170 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_x86_64.replies | 190 +++++-------------- tests/qemucapabilitiesdata/caps_5.2.0_x86_64.xml | 2 +- .../caps_6.0.0_aarch64.replies | 172 ++++------------- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.0.0_x86_64.replies | 188 +++++-------------- tests/qemucapabilitiesdata/caps_6.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_6.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.1.0_x86_64.xml | 2 +- .../caps_6.2.0_aarch64.replies | 178 ++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 2 +- .../caps_7.0.0_aarch64+hvf.replies | 182 +++++------------- .../caps_7.0.0_aarch64+hvf.xml | 2 +- .../caps_7.0.0_aarch64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_7.2.0_ppc.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 +- .../caps_7.2.0_x86_64+hvf.replies | 206 +++++---------------- .../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 2 +- .../qemucapabilitiesdata/caps_7.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 2 +- .../caps_8.0.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_8.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 2 +- .../caps_8.2.0_aarch64.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_armv7l.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 2 +- .../caps_8.2.0_loongarch64.replies | 186 ++++--------------- .../caps_8.2.0_loongarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 2 +- .../caps_9.1.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 2 +- tests/qemuhotplugtest.c | 8 +- .../qemuxmlconfdata/disk-cache.x86_64-latest.args | 3 +- .../disk-cdrom-bus-other.x86_64-latest.args | 3 +- .../disk-device-removable.x86_64-latest.args | 3 +- .../disk-usb-device.x86_64-latest.args | 3 +- 84 files changed, 1689 insertions(+), 5346 deletions(-) --- base-commit: e5299ddf86121d3c792ca271ffcb54900eb19dc3 change-id: 20250304-bot-5d84aa3a5cfe Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

4 11

[PATCH 0/2] esx: Allow specifying different CA bundle for remote connections
by Martin Kletzander 12 Jun '25

12 Jun '25

**El Blurbo aquí** Martin Kletzander (2): esx: Allow specifying different CA bundle for remote connections NEWS: Mention cainfo_path parameter in esx driver NEWS.rst | 5 +++++ docs/drvesx.rst | 16 ++++++++++++++-- src/esx/esx_util.c | 4 ++++ src/esx/esx_util.h | 1 + src/esx/esx_vi.c | 3 +++ 5 files changed, 27 insertions(+), 2 deletions(-) -- 2.49.0

2 6

[PATCH] storage: Implement a simple 'checkPool' method for 'rbd' type pools
by Krisstoffe 12 Jun '25

12 Jun '25

From: Krisstoffe <krisstoffe(a)free.fr> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/448 Signed-off-by: Krisstoffe <krisstoffe(a)free.fr> --- src/storage/storage_backend_rbd.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 038a1a9e34..29d544d349 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -1442,9 +1442,21 @@ virStorageBackendRBDVolWipe(virStoragePoolObj *pool, } +static int +virStorageBackendRBDCheckPool(virStoragePoolObj *pool, + bool *active) +{ + /* Return previous state remembered by the status XML. If the pool is not + * available we will fail to refresh it and end up in the same situation. */ + *active = virStoragePoolObjIsActive(pool); + return 0; +} + + virStorageBackend virStorageBackendRBD = { .type = VIR_STORAGE_POOL_RBD, + .checkPool = virStorageBackendRBDCheckPool, .refreshPool = virStorageBackendRBDRefreshPool, .createVol = virStorageBackendRBDCreateVol, .buildVol = virStorageBackendRBDBuildVol, -- 2.47.1

2 1

[RFC PATCH v4 0/4] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 12 Jun '25

12 Jun '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 support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v4: - Changed the target QEMU binary (Linaro's CCA/v8 version with added QMP functionality) - Added the 'armrme' variant to tests/qemucapabilitiesdata/README.rst. - Renamed data files to include '+armrme': - tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml - tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml - tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies - tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml - tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args - tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml - Reorganized the commits to ensure the tests pass even with partial application of the patch. [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. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [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. We added a QMP command to retrieve CCA info for test (See "[software version]" below). I need to check qemu_firmware.c to see if my CPU firmware supports CCA. Since it's not implemented yet, I'll wait until a Linux distributor provides me with a JSON file for CCA. We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the 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 enhanced with CCA QMP command and found at: https://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp which is based on Linaro QEMU (cca/latest) https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (1): tests: Adds Arm CCA support docs/formatdomain.rst | 43 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 145 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 29 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 98 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_9.2.0-virt.aarch64+armrme.xml | 244 + .../qemu_9.2.0.aarch64+armrme.xml | 244 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_9.2.0_aarch64+armrme.replies | 36754 ++++++++++++++++ .../caps_9.2.0_aarch64+armrme.xml | 540 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 34 files changed, 38398 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.5

1 4

Re: [RFC PATCH v3 4/6] qemucapabilitiestest: Adds Arm CCA support
by Peter Krempa 12 Jun '25

12 Jun '25

On Thu, May 29, 2025 at 05:10:48 +0000, Kazuhiro Abe (Fujitsu) wrote: > > On 5/20/25 17:54, Peter Krempa wrote: > > On Tue, May 20, 2025 at 17:28:26 +0900, Kazuhiro Abe wrote: > > > From: Akio Kakuno <fj3333bs(a)fujitsu.com> > > > > > > - This test was added to check qemu capabilities for Arm > > > CCA support. > > > > IF > > > > > This test was created using the method described in the > > > documentation. > > > > > > Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com> > > > --- > > > .../caps_9.1.0_aarch64.replies | 36222 > > ++++++++++++++++ > > > .../caps_9.1.0_aarch64.xml | 530 + > > > 2 files changed, 36752 insertions(+) > > > create mode 100644 > > > tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml > > > > Note that I'll be commenting only on the capability testing related matter, not the > > rest of the series. > > > > > diff --git a/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > new file mode 100644 > > > index 0000000000..906a21f0c6 > > > --- /dev/null > > > +++ b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > @@ -0,0 +1,36222 @@ > > > +{ > > > + "execute": "qmp_capabilities", > > > + "id": "libvirt-1" > > > +} > > > + > > > +{ > > > + "return": {}, > > > + "id": "libvirt-1" > > > +} > > > + > > > +{ > > > + "execute": "query-version", > > > + "id": "libvirt-2" > > > +} > > > + > > > +{ > > > + "return": { > > > + "qemu": { > > > + "micro": 91, > > > + "minor": 1, > > > + "major": 9 > > > > This is from 9.2.0-rc1. So firstly the file is named wrong, because it was supposed > > to be 'caps_9.2.0_aarch64.replies' instead. > > > > Also except for the currently developed release we require that the .replies files > > are generated from the final release versions and not the RCs or any other > > non-final code. > > > > The libvirt tree already has qemu caps for 9.2.0 and 10.0.0 for aarch64. > > > > What makes these special? > > > > If there's a reason to have specific capabilities please add a 'variant' > > per tests/qemucapabilitiesdata/README.rst > > Thanks for your comment. > > These were generated from a special QEMU version which support ARM CCA based on 9.2. > So as a temporary measure, I will add a variant to the replies file, > and the name will be caps_9.2.0_aarch64+armrme.replies. I'd expect that now that qemu-10.0 is out you'd be targetting at least qemu-10.1 [1] as ... > > Note that, once the patch about Arm CCA support is merged, > we will change the replies file name. ... it's not yet merged as you are saying. [1] We do allow capabilities captured from the currently in development tree but: - they must be based on a commit from official qemu git - you will have to update them to the final version once qemu-N+1 releases. But since it's not merged yet your patch will need to stay RFC. Please make sure thoug to note it in the capabilities patch that it's not the final version yet so that there's no confusion. Your patch looked like it was something which already exists based on the commit message and I didn't read the cover letter because I wasn't too interested in the series itself, I'm just making sure that capabilities dumps are handled properly so that I don't have to deal with it later.

2 1

[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober 10 Jun '25

10 Jun '25

This change serves as a proof of concept that adds live migration support to the Cloud Hypervisor driver. It is meant to show feasibility and to receive early feedback. I tested the live migration by invoking: virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live Opens: * What is required for a minimal viable live migration to be merged? * Job state tracking? (virDomainObjBeginJob, ...) * What should 'virsh domjobinfo' show? * Testing? * Anything else? Stefan Kober (1): Initial CH migrate API src/ch/ch_conf.h | 4 + src/ch/ch_domain.h | 2 + src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++- src/ch/ch_monitor.c | 156 +++++++++++++ src/ch/ch_monitor.h | 8 + src/ch/ch_process.c | 136 ++++++++++- src/ch/ch_process.h | 6 + src/hypervisor/domain_interface.c | 1 + src/libvirt-domain.c | 15 +- 9 files changed, 680 insertions(+), 10 deletions(-) -- 2.49.0

3 5

[PATCH] docs: fix list term highlighting in URI docs
by Daniel P. Berrangé 10 Jun '25

10 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Having a blank line between the term and its definition prevents the RST to HTML convertor highlighting 'pkipath' correctly. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/uri.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/uri.rst b/docs/uri.rst index 1d2c68f5b8..cc970001f4 100644 --- a/docs/uri.rst +++ b/docs/uri.rst @@ -296,7 +296,6 @@ Supported extra parameters: **Example:** ``no_verify=1`` ``pkipath`` - Specifies x509 certificates path for the client. If any of the CA certificate, client certificate, or client key is missing, the connection will fail with a fatal error. -- 2.49.0

2 1

Question about managed/unmanaged persistent reservation disks
by Annie Li 09 Jun '25

09 Jun '25

Hello, I've been looking at source code related to persistent reservation and got confused a little bit about managed persistent reservation disks. For disk configured with 'managed=yes' as the following, <reservations managed='yes'> <source type='unix' path='/var/lib/libvirt/qemu/domain-7-brml10g19-iscsi-rese/pr-helper0.sock' mode='client'/> </reservations> libvirt is responsible for starting a pr-helper program with a specific associated socket file. The following source code shows that there is only one pr-helper and socket file associated with the managed disks for one VM. const char * qemuDomainGetManagedPRAlias(void) { return "pr-helper0"; } char * qemuDomainGetManagedPRSocketPath(qemuDomainObjPrivate *priv) { return g_strdup_printf("%s/%s.sock", priv->libDir, qemuDomainGetManagedPRAlias()); } So if the VM is booted with multiple disks configured with 'managed=yes' for reservation, I suppose these multiple disks share the this managed pr-helper and socket file. However, per the qemu document, https://www.qemu.org/docs/master/interop/pr-helper.html <https://www.qemu.org/docs/master/interop/pr-helper.html> "It is invalid to send multiple commands concurrently on the same socket. It is however possible to connect multiple sockets to the helper and send multiple commands to the helper for one or more file descriptors." Due to this limitation above, only one persistent reservation disk is allowed as managed in theory. However, libvirt doesn't throw out any error or warning when the VM is booted up with multiple managed persistent reservation disks. I am wondering if I've missed something here? For unmanaged persistent reservation disks, libvirt doesn't start the pr-helper program for them. It is user's responsibility to start this program with customized socket file per disk, but the complexity increases with numbers of persistent reservation disks, especially in the case of hotplug/hotunplog. Is there any plan to support multiple managed persistent reservation disks with separate pr-helper/socket file? Any suggestions/clarifications are greatly appreciated. Thanks Annie

1 0

[PATCH] nvme: Fix more missing enum switches for VIR_DOMAIN_DISK_BUS_NVME
by Martin Kletzander 09 Jun '25

09 Jun '25

From: Martin Kletzander <mkletzan(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- So it turned out there were more places, but some even in code that was compiling on my machine and in the CI, but was not found. Not sure why, but I went through all the places again from scratch, hopefully this time that's all. Pushed. src/bhyve/bhyve_domain.c | 1 + src/qemu/qemu_validate.c | 1 + src/vz/vz_sdk.c | 2 ++ src/vz/vz_utils.c | 1 + 4 files changed, 5 insertions(+) diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c index 3e18a462e460..c9bbf27d83ca 100644 --- a/src/bhyve/bhyve_domain.c +++ b/src/bhyve/bhyve_domain.c @@ -143,6 +143,7 @@ bhyveDomainDiskDefAssignAddress(struct _bhyveConn *driver, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: break; diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 5eaaca87fed6..b2faf4300204 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -1556,6 +1556,7 @@ qemuValidateDomainDeviceDefAddressDrive(virDomainDeviceInfo *info, case VIR_DOMAIN_DISK_BUS_SD: case VIR_DOMAIN_DISK_BUS_NONE: case VIR_DOMAIN_DISK_BUS_UML: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: break; } diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 684b76ffa057..160778146dcd 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3380,6 +3380,7 @@ static int prlsdkConfigureDisk(struct _vzDriver *driver, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", @@ -4339,6 +4340,7 @@ prlsdkGetBlockStats(PRL_HANDLE sdkstats, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_INTERNAL_ERROR, diff --git a/src/vz/vz_utils.c b/src/vz/vz_utils.c index 7c08d0f88b58..976303479bb6 100644 --- a/src/vz/vz_utils.c +++ b/src/vz/vz_utils.c @@ -242,6 +242,7 @@ vzCheckDiskAddressDriveUnsupportedParams(virDomainDiskDef *disk) case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", -- 2.49.0

2 1

[PATCH 0/3] Drop unnecessary build dependencies
by Andrea Bolognani 09 Jun '25

09 Jun '25

We've recently stopped checking for the presence of several commands at build time. That means we don't need them in the RPM or CI build environment either. Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1855622714 Andrea Bolognani (3): rpm: Fix/clarify Requires rpm: Drop unnecessary BuildRequires ci: Drop unnecessary build dependencies ci/buildenv/almalinux-9.sh | 9 --------- ci/buildenv/alpine-321.sh | 6 ------ ci/buildenv/alpine-edge.sh | 6 ------ ci/buildenv/centos-stream-9.sh | 9 --------- ci/buildenv/debian-12-cross-aarch64.sh | 8 -------- ci/buildenv/debian-12-cross-armv6l.sh | 8 -------- ci/buildenv/debian-12-cross-armv7l.sh | 8 -------- ci/buildenv/debian-12-cross-i686.sh | 8 -------- ci/buildenv/debian-12-cross-mips64el.sh | 8 -------- ci/buildenv/debian-12-cross-mipsel.sh | 8 -------- ci/buildenv/debian-12-cross-ppc64le.sh | 8 -------- ci/buildenv/debian-12-cross-s390x.sh | 8 -------- ci/buildenv/debian-12.sh | 8 -------- ci/buildenv/debian-sid-cross-aarch64.sh | 8 -------- ci/buildenv/debian-sid-cross-armv6l.sh | 8 -------- ci/buildenv/debian-sid-cross-armv7l.sh | 8 -------- ci/buildenv/debian-sid-cross-i686.sh | 8 -------- ci/buildenv/debian-sid-cross-mips64el.sh | 8 -------- ci/buildenv/debian-sid-cross-ppc64le.sh | 8 -------- ci/buildenv/debian-sid-cross-s390x.sh | 8 -------- ci/buildenv/debian-sid.sh | 8 -------- ci/buildenv/fedora-41.sh | 9 --------- ci/buildenv/fedora-42-cross-mingw32.sh | 9 --------- ci/buildenv/fedora-42-cross-mingw64.sh | 9 --------- ci/buildenv/fedora-42.sh | 9 --------- ci/buildenv/fedora-rawhide-cross-mingw32.sh | 9 --------- ci/buildenv/fedora-rawhide-cross-mingw64.sh | 9 --------- ci/buildenv/fedora-rawhide.sh | 9 --------- ci/buildenv/opensuse-leap-15.sh | 8 -------- ci/buildenv/opensuse-tumbleweed.sh | 8 -------- ci/buildenv/ubuntu-2204.sh | 8 -------- ci/buildenv/ubuntu-2404.sh | 8 -------- ci/cirrus/freebsd-13.vars | 2 +- ci/cirrus/freebsd-14.vars | 2 +- ci/containers/almalinux-9.Dockerfile | 9 --------- ci/containers/alpine-321.Dockerfile | 6 ------ ci/containers/alpine-edge.Dockerfile | 6 ------ ci/containers/centos-stream-9.Dockerfile | 9 --------- .../debian-12-cross-aarch64.Dockerfile | 8 -------- .../debian-12-cross-armv6l.Dockerfile | 8 -------- .../debian-12-cross-armv7l.Dockerfile | 8 -------- ci/containers/debian-12-cross-i686.Dockerfile | 8 -------- .../debian-12-cross-mips64el.Dockerfile | 8 -------- .../debian-12-cross-mipsel.Dockerfile | 8 -------- .../debian-12-cross-ppc64le.Dockerfile | 8 -------- ci/containers/debian-12-cross-s390x.Dockerfile | 8 -------- ci/containers/debian-12.Dockerfile | 8 -------- .../debian-sid-cross-aarch64.Dockerfile | 8 -------- .../debian-sid-cross-armv6l.Dockerfile | 8 -------- .../debian-sid-cross-armv7l.Dockerfile | 8 -------- ci/containers/debian-sid-cross-i686.Dockerfile | 8 -------- .../debian-sid-cross-mips64el.Dockerfile | 8 -------- .../debian-sid-cross-ppc64le.Dockerfile | 8 -------- .../debian-sid-cross-s390x.Dockerfile | 8 -------- ci/containers/debian-sid.Dockerfile | 8 -------- ci/containers/fedora-41.Dockerfile | 9 --------- .../fedora-42-cross-mingw32.Dockerfile | 9 --------- .../fedora-42-cross-mingw64.Dockerfile | 9 --------- ci/containers/fedora-42.Dockerfile | 9 --------- .../fedora-rawhide-cross-mingw32.Dockerfile | 9 --------- .../fedora-rawhide-cross-mingw64.Dockerfile | 9 --------- ci/containers/fedora-rawhide.Dockerfile | 9 --------- ci/containers/opensuse-leap-15.Dockerfile | 8 -------- ci/containers/opensuse-tumbleweed.Dockerfile | 8 -------- ci/containers/ubuntu-2204.Dockerfile | 8 -------- ci/containers/ubuntu-2404.Dockerfile | 8 -------- ci/lcitool/projects/libvirt.yml | 9 --------- libvirt.spec.in | 18 +++--------------- 68 files changed, 5 insertions(+), 548 deletions(-) -- 2.49.0

2 4

[PATCH] bhyve: Fix build after introduction of emulated NVMe disks
by Martin Kletzander 09 Jun '25

09 Jun '25

From: Martin Kletzander <mkletzan(a)redhat.com> Somehow I missed one switch over disk bus enum. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed under the 'build-breaker' rule. src/bhyve/bhyve_command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 916d699c8030..c82a07c2eb1d 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -370,6 +370,7 @@ bhyveBuildDiskArgStr(const virDomainDef *def, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", -- 2.49.0

1 0

[PATCH] docs: outline bug expectations wrt automated tools / AI agents
by Daniel P. Berrangé 09 Jun '25

09 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Bug reports from automated tools and AI agents are time consuming to triage and have poor signal/noise ratio. Set strong expectations for any reporters using such tools, in a (likely doomed) attempt to stem the flow of poor quality reports. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/bugs.rst | 14 ++++++++++++++ docs/securityprocess.rst | 4 ++++ 2 files changed, 18 insertions(+) diff --git a/docs/bugs.rst b/docs/bugs.rst index 5fd1970caf..e12a6c74ec 100644 --- a/docs/bugs.rst +++ b/docs/bugs.rst @@ -76,6 +76,20 @@ Linux Distribution specific bug reports like to have your procedure for filing bugs mentioned here, please mail the libvirt development list. +Use of automated tools / AI agents +---------------------------------- + +If any automated tool / AI agent is used to identify a bug / security +flaw, the following additional expectations apply when filing a report: + +- The tool / agent used **MUST** be clearly declared in the description +- All stated facts **MUST** be validated as correct and free from AI + hallucinations prior to filing +- The problem **MUST** be described against an upstream release that is + no more than 3 months old. +- The problem **SHOULD** be analysed and accompanied with a proposed + patch that can be directly applied to current git + How to file high quality bug reports ------------------------------------ diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst index 075679df74..b7695ddc59 100644 --- a/docs/securityprocess.rst +++ b/docs/securityprocess.rst @@ -27,6 +27,10 @@ and moderated for non-members. As such you will receive an auto-reply indicating the report is held for moderation. Postings by non-members will be approved by a moderator and the reporter copied on any replies. +Refer to the `bug reporting <bugs.html#use-of-automated-tools-ai-agents>`__ +page for the *expectations around the use of automated tools and AI agents*, +**prior** to filing any security report. + Security notices ---------------- -- 2.49.0

3 5

Re: Can you have a brief look? [Was: Support for emulated NVMe disks in VMX and QEMU]
by Martin Kletzander 09 Jun '25

09 Jun '25

[Adding the list to Cc] On Fri, Jun 06, 2025 at 12:19:16PM +0800, Honglei Wang wrote: >Hi Martin, > >Thanks for following up — yes, I saw your previous email and just had a >chance to review the patches. > >The series looks good to me overall, and I’m fine with the Signed-off-by >trailers you added — thanks for including them. > Thank you for the confirmation. >There might be a small detail to look into: I noticed you changed the >parameters of the virIndexToDiskName function, but it seems not all callers >were updated accordingly. This should be caught by CI, though. If I have >any other issues, I’ll reply on the patch mail list. > You are right, I missed the hyperv driver for some reason. I fixed that in the commit which changes the parameters and pushed the series upstream so that it gets to the next release. >Thanks again for your work on this! > >Best regards > Thank you too and have a nice day, Martin

1 0

[PATCH v3 0/2] Fix forward type=hostdev nets for apparmor
by Tim Small 09 Jun '25

09 Jun '25

Fixes a bug whereby apparmor permissions aren't granted to allow a PCI SR-IOV virtual function to be used in a kvm guest when the VF is defined via a forward type='hostdev' network (as per the 'hostdev' option documented here: https://libvirt.org/formatnetwork.html#connectivity ). Downstream bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856 qemu accesses these PCI virtual functions using the vfio API, so no additional permissions to access to the PCI device resources etc. via /sys/devices/pci[...]/resource et al. are necessary. This is a resend with fixed From in body for the patch emails, and change notes in patch emails. Thanks, Tim. Tim Small (2): virt-aa-helper: refactor for readability virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks .../usr.lib.libvirt.virt-aa-helper.in | 4 +++ src/security/virt-aa-helper.c | 28 ++++++++++++++++--- 2 files changed, 28 insertions(+), 4 deletions(-) -- 2.47.2

2 4