- Devel - libvirt List Archives

[PATCH 00/14] Synchronize CPU models and features with QEMU 11.0
by Jiri Denemark 20 May '26

20 May '26

Jiri Denemark (14): sync_qemu_models_i386: Remove forgotten parentheses sync_qemu_models_i386: Convert family/model to decimal cpu_map: Add gmet and vmx-mbec features for nested virtualization cpu_map: Add CPUID features for AMX instructions cpu_map: Add CET related CPU features cpu_map: Add CPUID feature for MOVRS cpu_map: Add avx10-vnni-int CPU feature cpu_map: Add APX (Advanced Performance Extensions) CPUID features sync_qemu_models_i386: Add missing features to translation map cpu_map: Add new versions of ClearwaterForest CPU model cpu_map: Add new versions of SierraForest CPU model cpu_map: Add new versions of SapphireRapids CPU model cpu_map: Add new versions of GraniteRapids CPU model cpu_map: Add DiamondRapids CPU model src/cpu_map/index.xml | 10 + src/cpu_map/meson.build | 10 + src/cpu_map/sync_qemu_models_i386.py | 33 +- src/cpu_map/x86_ClearwaterForest-v2.xml | 197 +++++++ src/cpu_map/x86_ClearwaterForest-v3.xml | 198 ++++++++ src/cpu_map/x86_DiamondRapids-v1.xml | 6 + src/cpu_map/x86_DiamondRapids.xml | 248 +++++++++ src/cpu_map/x86_GraniteRapids-v4.xml | 210 ++++++++ src/cpu_map/x86_GraniteRapids-v5.xml | 211 ++++++++ src/cpu_map/x86_SapphireRapids-v5.xml | 202 ++++++++ src/cpu_map/x86_SapphireRapids-v6.xml | 203 ++++++++ src/cpu_map/x86_SierraForest-v4.xml | 190 +++++++ src/cpu_map/x86_SierraForest-v5.xml | 191 +++++++ src/cpu_map/x86_features.xml | 60 +++ .../x86_64-cpuid-Core-i7-1270P-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-1270P-guest.xml | 2 + .../x86_64-cpuid-Core-i7-1270P-host.xml | 2 + .../x86_64-cpuid-Core-i7-1365U-disabled.xml | 2 +- .../x86_64-cpuid-Core-i7-1365U-guest.xml | 2 + .../x86_64-cpuid-Core-i7-1365U-host.xml | 2 + ...86_64-cpuid-EPYC-7502-32-Core-disabled.xml | 2 +- .../x86_64-cpuid-EPYC-7502-32-Core-guest.xml | 1 + .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 1 + ...86_64-cpuid-EPYC-7713-64-Core-disabled.xml | 4 +- .../x86_64-cpuid-EPYC-7713-64-Core-guest.xml | 2 + .../x86_64-cpuid-EPYC-7713-64-Core-host.xml | 2 + ...86_64-cpuid-EPYC-9334-32-Core-disabled.xml | 4 +- .../x86_64-cpuid-EPYC-9334-32-Core-guest.xml | 2 + .../x86_64-cpuid-EPYC-9334-32-Core-host.xml | 2 + ...-5-5500U-with-Radeon-Graphics-disabled.xml | 2 +- ...zen-5-5500U-with-Radeon-Graphics-guest.xml | 1 + ...yzen-5-5500U-with-Radeon-Graphics-host.xml | 1 + ...4-cpuid-Ryzen-9-3900X-12-Core-disabled.xml | 2 +- ...6_64-cpuid-Ryzen-9-3900X-12-Core-guest.xml | 1 + ...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml | 1 + ...4-cpuid-Ryzen-9-9950X-16-Core-disabled.xml | 4 +- ...6_64-cpuid-Ryzen-9-9950X-16-Core-guest.xml | 2 + ...86_64-cpuid-Ryzen-9-9950X-16-Core-host.xml | 2 + .../x86_64-cpuid-Xeon-6731E-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-6731E-guest.xml | 2 + .../x86_64-cpuid-Xeon-6731E-host.xml | 2 + .../x86_64-cpuid-Xeon-6788P-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-6788P-guest.xml | 2 + .../x86_64-cpuid-Xeon-6788P-host.xml | 2 + ...86_64-cpuid-Xeon-Bronze-3408U-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-Bronze-3408U-guest.xml | 2 + .../x86_64-cpuid-Xeon-Bronze-3408U-host.xml | 2 + .../x86_64-cpuid-Xeon-Gold-6530-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6530-guest.xml | 2 + .../x86_64-cpuid-Xeon-Gold-6530-host.xml | 2 + .../x86_64-cpuid-Xeon-w7-3465X-disabled.xml | 2 +- .../x86_64-cpuid-Xeon-w7-3465X-guest.xml | 2 + .../x86_64-cpuid-Xeon-w7-3465X-host.xml | 2 + .../qemu_11.0.0-q35.x86_64+sgx.xml | 373 ++++++++++++++ .../domaincapsdata/qemu_11.0.0-q35.x86_64.xml | 373 ++++++++++++++ .../qemu_11.0.0-tcg.x86_64+sgx.xml | 480 ++++++++++++++++++ .../domaincapsdata/qemu_11.0.0-tcg.x86_64.xml | 480 ++++++++++++++++++ .../domaincapsdata/qemu_11.0.0.x86_64+sgx.xml | 373 ++++++++++++++ tests/domaincapsdata/qemu_11.0.0.x86_64.xml | 373 ++++++++++++++ ...host-model-fallback-kvm.x86_64-11.0.0.args | 2 +- ...host-model-fallback-kvm.x86_64-latest.args | 2 +- ...cpu-host-model-features.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-11.0.0.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...st-model-nofallback-kvm.x86_64-11.0.0.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- 66 files changed, 4487 insertions(+), 26 deletions(-) create mode 100644 src/cpu_map/x86_ClearwaterForest-v2.xml create mode 100644 src/cpu_map/x86_ClearwaterForest-v3.xml create mode 100644 src/cpu_map/x86_DiamondRapids-v1.xml create mode 100644 src/cpu_map/x86_DiamondRapids.xml create mode 100644 src/cpu_map/x86_GraniteRapids-v4.xml create mode 100644 src/cpu_map/x86_GraniteRapids-v5.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v5.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v6.xml create mode 100644 src/cpu_map/x86_SierraForest-v4.xml create mode 100644 src/cpu_map/x86_SierraForest-v5.xml -- 2.54.0

2 15

[PATCH 0/4] bhyve: add memtune support
by Roman Bogorodskiy 20 May '26

20 May '26

Roman Bogorodskiy (4): bhyve: add memtune support bhyve: implement the domainGetMemoryParameters API bhyve: process: factor out rctl(8) code bhyve: implement the domainSetMemoryParameters API src/bhyve/bhyve_domain.c | 8 ++ src/bhyve/bhyve_driver.c | 130 +++++++++++++++++ src/bhyve/bhyve_process.c | 32 ++--- src/bhyve/bhyve_rctl.c | 135 ++++++++++++++++++ src/bhyve/bhyve_rctl.h | 32 +++++ src/bhyve/meson.build | 1 + ...vexml2argv-memtune-unsupported-params.args | 10 ++ ...xml2argv-memtune-unsupported-params.ldargs | 4 + ...yvexml2argv-memtune-unsupported-params.xml | 28 ++++ .../x86_64/bhyvexml2argv-memtune.args | 10 ++ .../x86_64/bhyvexml2argv-memtune.ldargs | 4 + .../x86_64/bhyvexml2argv-memtune.xml | 26 ++++ tests/bhyvexml2argvtest.c | 2 + 13 files changed, 402 insertions(+), 20 deletions(-) create mode 100644 src/bhyve/bhyve_rctl.c create mode 100644 src/bhyve/bhyve_rctl.h create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune-unsupported-params.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune-unsupported-params.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune-unsupported-params.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-memtune.xml -- 2.52.0

2 5

[PATCH] conf: Assert virDomainChrDeviceState and virConnectDomainEventAgentLifecycleState enums are in sync
by Michal Privoznik 20 May '26

20 May '26

From: Michal Privoznik <mprivozn(a)redhat.com> When QEMU driver emits agent connected/disconnected events (inside of processSerialChangedEvent()) it declares a variable of virDomainChrDeviceState enum, and then passes this variable to virDomainEventAgentLifecycleNewFromObj(). But we document the agent lifecycle state to be of virConnectDomainEventAgentLifecycleState enum. Therefore, make sure values from virConnectDomainEventAgentLifecycleState enum are of the same value as those invirDomainChrDeviceState enum. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index bdfb99ed1d..d17f6352bd 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1243,6 +1243,11 @@ typedef enum { VIR_DOMAIN_CHR_DEVICE_STATE_LAST } virDomainChrDeviceState; +G_STATIC_ASSERT((int)VIR_DOMAIN_CHR_DEVICE_STATE_CONNECTED == + (int)VIR_CONNECT_DOMAIN_EVENT_AGENT_LIFECYCLE_STATE_CONNECTED); +G_STATIC_ASSERT((int)VIR_DOMAIN_CHR_DEVICE_STATE_DISCONNECTED == + (int)VIR_CONNECT_DOMAIN_EVENT_AGENT_LIFECYCLE_STATE_DISCONNECTED); + VIR_ENUM_DECL(virDomainChrDeviceState); typedef enum { -- 2.53.0

2 1

[PATCH] cpu_map: Add Neoverse-V2 CPU model
by Jonathan Davies 20 May '26

20 May '26

Add Neoverse V2 as a supported cpu model. Signed-off-by: Jonathan Davies <jonathan.davies(a)nutanix.com> --- src/cpu_map/arm_Neoverse-V2.xml | 6 ++++++ src/cpu_map/index.xml | 1 + src/cpu_map/meson.build | 1 + 3 files changed, 8 insertions(+) create mode 100644 src/cpu_map/arm_Neoverse-V2.xml diff --git a/src/cpu_map/arm_Neoverse-V2.xml b/src/cpu_map/arm_Neoverse-V2.xml new file mode 100644 index 0000000000..b8d75ad602 --- /dev/null +++ b/src/cpu_map/arm_Neoverse-V2.xml @@ -0,0 +1,6 @@ +<cpus> + <model name='Neoverse-V2'> + <vendor name='ARM'/> + <pvr value='0xd4f'/> + </model> +</cpus> diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 57a28d1d1d..82f3f95166 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -220,6 +220,7 @@ <include filename='arm_Neoverse-N1.xml'/> <include filename='arm_Neoverse-N2.xml'/> <include filename='arm_Neoverse-V1.xml'/> + <include filename='arm_Neoverse-V2.xml'/> </group> <group name='Qualcomm-based CPU models'> diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index 2b6b1bf3ea..952be9296c 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -12,6 +12,7 @@ cpumap_data = [ 'arm_Neoverse-N1.xml', 'arm_Neoverse-N2.xml', 'arm_Neoverse-V1.xml', + 'arm_Neoverse-V2.xml', 'arm_Tengyun-S2500.xml', 'arm_ThunderX299xx.xml', 'arm_vendors.xml', -- 2.43.0

2 1

[PATCH] NEWS: add latest ZFS driver changes
by George Melikov 19 May '26

19 May '26

From: George Melikov <mail(a)gmelikov.ru> Signed-off-by: George Melikov <mail(a)gmelikov.ru> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 2ecea251da..6ef55124a7 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -25,8 +25,20 @@ v12.4.0 (unreleased) * **Improvements** + * storage: ZFS: Implement native volume resizing (since v11.7.0) + + The ZFS storage driver now supports ``resizeVol`` allowing online + resizing of zvols via ``zfs set volsize``. Since ZFS is always + thin-provisioned, resize is essentially a size limit change. + * **Bug fixes** + * storage: ZFS: Fix incorrect volsize and refreservation on zvol creation + + When creating a zvol, the ZFS driver listed all volumes in the pool and + updated the new volume's size with data from the last volume in the list + rather than the matching one. Now it correctly returns on valid one. + * esx/vmware: VMs are tracked under different UUIDs by default The VMWare-related drivers were using allegedly unique IDs for domains, but -- 2.53.0

2 1

[PATCH 0/2] virnetdevbandwidth: Only clear qdisc for defined directions
by Wesley Hershberger 19 May '26

19 May '26

The first part of this description is taken from the bug report: https://gitlab.com/libvirt/libvirt/-/work_items/875 By default, a macvtap device will have the qdisc for the tap set to `noqueue` to prevent lock contention limiting the available bandwidth for the VM (see [BZ 1329644](https://bugzilla.redhat.com/show_bug.cgi?id=1329644)) ```xml <interface type='direct'> <mac address='52:54:00:f5:7e:97'/> <source dev='ens2f0np0' mode='passthrough'/> <target dev='macvtap0'/> <model type='virtio'/> <alias name='net1'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </interface> ``` ``` 12: macvtap0@ens2f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500 ``` However, defining an interface with only an `inbound` bandwidth limit sets the iface's root qdisc to the system default: ```xml <interface type='direct'> <mac address='52:54:00:05:8f:18'/> <source dev='ens2f0np0' mode='passthrough'/> <bandwidth> <inbound average='3125000' peak='3125000'/> </bandwidth> <target dev='macvtap5'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> ``` ``` 16: macvtap5@ens2f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500 ``` If I understand correctly, the `root` and `ingress` directions can be configured independently. So the above bandwidth definition should correspond to this (configured manually): ``` $ sudo tc qdisc show dev macvtap5 qdisc noqueue 8007: root refcnt 2 qdisc ingress ffff: parent ffff:fff1 ---------------- ``` Rather than: ``` $ sudo tc qdisc show dev macvtap6 qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc ingress ffff: parent ffff:fff1 ---------------- ``` When libvirt sets up a macvtap device, qemuDomainInterfaceSetDefaultQDisc configures qdisc noqueue for the interface. However, if bandwidth limits are defined, it also calls virNetDevBandwidthSet, which will call virNetDevBandwidthClear before reconfiguring the qdisc for the tx/rx. If only rx is defined, the root qdisc will be the system default. d53b0923539 prevents the noqueue configuration from being lost when reconfiguring bandwidth limits. All usages of virNetDevBandwidthSet are either covered by a call to qemuDomainInterfaceSetDefaultQDisc or qdisc noqueue does not apply there. This change doesn't change the semantics of virNetDevBandwidthClear. Alternatively, virNetDevBandwidthSet/virNetDevBandwidthClear could take a default qdisc which would be used to call virNetDevBandwidthSetRootQDisc in virNetDevBandwidthClear, removing the need for the two changes in d53b0923539. I've confirmed that the fix works when creating a domain with an ingress-only bandwidth limit. Please let me know what you think. Thanks! Signed-off-by: Wesley Hershberger <wesley.hershberger(a)canonical.com> --- Wesley Hershberger (2): virnetdevbandwidth: Split virNetDevBandwidthClear into two helpers virnetdevbandwidth: Only clear qdisc for defined directions src/util/virnetdevbandwidth.c | 70 +++++++++++++++++++++++++++++-------------- src/util/virnetdevbandwidth.h | 2 ++ 2 files changed, 49 insertions(+), 23 deletions(-) --- base-commit: 543280d8c8fe06526ce9871e7d25f46f6ee89017 change-id: 20260506-qdisc-clear-11a1f86407a2 Best regards, -- Wesley Hershberger <wesley.hershberger(a)canonical.com>

2 5

[PATCH] virTypedParamsValidateTemplate: Fix counting of templates
by Peter Krempa 19 May '26

19 May '26

From: Peter Krempa <pkrempa(a)redhat.com> There are 2 bugs in virTypedParamsValidateTemplate's counting of the passed amount of templates: - the condition looked for empty strings rather than non-empty ones - the count was 1 more than the amount of templates due to use of post-increment directly in the condition Fixes: 45617351585caa2c5bcc51af48bd32fd750e7afd Closes: https://gitlab.com/libvirt/libvirt/-/work_items/880 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virtypedparam.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/virtypedparam.c b/src/util/virtypedparam.c index 92f25cea39..bca7478109 100644 --- a/src/util/virtypedparam.c +++ b/src/util/virtypedparam.c @@ -213,8 +213,8 @@ virTypedParamsValidateTemplate(virTypedParameterPtr params, /* we need to copy the list of templates because * 'virTypedParamsValidateInternal' will need to sort it */ - while (*templates[ntemplates++].name == '\0') - ; + while (*templates[ntemplates].name != '\0') + ntemplates++; templ_copy = g_new0(virTypedParamValidationTemplate, ntemplates); memcpy(templ_copy, templates, sizeof(*templates) * ntemplates); -- 2.54.0

2 1

[PATCH] Revert "esx: switch VIR_FREE->g_free in esx*Free*()"
by Martin Kletzander 19 May '26

19 May '26

From: Martin Kletzander <mkletzan(a)redhat.com> This reverts commit 443c79dd7f7d4051fc0084baaa6c56a55d2aace4. Change from VIR_FREE() to g_free meant there is a possible double free when there is an error during parsing because the parsing it done directly into the parsedUri member of the esxPrivate, free'd when it fails and then the caller calls free on it again. Changing back to VIR_FREE() means there is no double free and no crash. Reproducible easily with `virsh -c esx://l?no_verify=2`. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/esx/esx_driver.c | 2 +- src/esx/esx_stream.c | 4 ++-- src/esx/esx_util.c | 13 +++++++------ 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index 010c62b8e880..6ff0db48ac02 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -63,7 +63,7 @@ esxFreePrivate(esxPrivate **priv) esxUtil_FreeParsedUri(&(*priv)->parsedUri); virObjectUnref((*priv)->caps); virObjectUnref((*priv)->xmlopt); - g_free(*priv); + VIR_FREE(*priv); } diff --git a/src/esx/esx_stream.c b/src/esx/esx_stream.c index 143b2405ed49..c1dd80806feb 100644 --- a/src/esx/esx_stream.c +++ b/src/esx/esx_stream.c @@ -321,8 +321,8 @@ esxFreeStreamPrivate(esxStreamPrivate **priv) return; esxVI_CURL_Free(&(*priv)->curl); - g_free((*priv)->backlog); - g_free(*priv); + VIR_FREE((*priv)->backlog); + VIR_FREE(*priv); } static int diff --git a/src/esx/esx_util.c b/src/esx/esx_util.c index a6275babd542..1443ec3b9e46 100644 --- a/src/esx/esx_util.c +++ b/src/esx/esx_util.c @@ -165,13 +165,14 @@ esxUtil_FreeParsedUri(esxUtil_ParsedUri **parsedUri) if (!parsedUri || !(*parsedUri)) return; - g_free((*parsedUri)->transport); - g_free((*parsedUri)->vCenter); - g_free((*parsedUri)->proxy_hostname); - g_free((*parsedUri)->path); - g_free((*parsedUri)->cacert); - g_free(*parsedUri); + VIR_FREE((*parsedUri)->transport); + VIR_FREE((*parsedUri)->vCenter); + VIR_FREE((*parsedUri)->proxy_hostname); + VIR_FREE((*parsedUri)->path); + VIR_FREE((*parsedUri)->cacert); + + VIR_FREE(*parsedUri); } -- 2.54.0

3 4

[PATCH 0/5] buildsys: Remove support for MIPS host
by Philippe Mathieu-Daudé 18 May '26

18 May '26

During the v10.2 development cycle we deprecated MIPS host support (mostly because Debian which we use to test in our CI dropped the architecture when releasing Debian 13). This series removes host support for MIPS. Philippe Mathieu-Daudé (5): buildsys: Remove MIPS cross containers buildsys: Remove support for MIPS hosts hw/mips: Include missing 'cpu.h' header buildsys: Remove MIPS KVM buildsys: Remove MIPS TCG backend MAINTAINERS | 15 - docs/about/deprecated.rst | 8 - docs/about/removed-features.rst | 6 + docs/system/target-mips.rst | 2 - configure | 20 - meson.build | 12 +- include/qemu/timer.h | 30 - include/user/thunk.h | 2 +- linux-user/include/host/mips64/host-signal.h | 75 - target/mips/kvm_mips.h | 28 - tcg/mips64/tcg-target-con-set.h | 30 - tcg/mips64/tcg-target-con-str.h | 20 - tcg/mips64/tcg-target-has.h | 69 - tcg/mips64/tcg-target-mo.h | 13 - tcg/mips64/tcg-target.h | 75 - tcg/mips64/tcg-target-opc.h.inc | 1 - hw/intc/mips_gic.c | 11 +- hw/mips/loongson3_virt.c | 67 +- hw/mips/malta.c | 1 - hw/mips/mips_int.c | 7 +- linux-user/mmap.c | 2 +- target/mips/cpu.c | 5 - target/mips/kvm.c | 1283 -------- target/mips/system/cp0_timer.c | 12 +- target/mips/system/physaddr.c | 1 - util/cacheflush.c | 16 - tcg/mips64/tcg-target.c.inc | 2605 ----------------- .gitlab-ci.d/container-cross.yml | 6 - .gitlab-ci.d/containers.yml | 1 - .gitlab-ci.d/crossbuilds.yml | 22 - target/mips/meson.build | 6 +- tests/docker/Makefile.include | 1 - .../dockerfiles/debian-mips64el-cross.docker | 187 -- .../dockerfiles/debian-mipsel-cross.docker | 187 -- tests/lcitool/refresh | 12 - 35 files changed, 32 insertions(+), 4806 deletions(-) delete mode 100644 linux-user/include/host/mips64/host-signal.h delete mode 100644 target/mips/kvm_mips.h delete mode 100644 tcg/mips64/tcg-target-con-set.h delete mode 100644 tcg/mips64/tcg-target-con-str.h delete mode 100644 tcg/mips64/tcg-target-has.h delete mode 100644 tcg/mips64/tcg-target-mo.h delete mode 100644 tcg/mips64/tcg-target.h delete mode 100644 tcg/mips64/tcg-target-opc.h.inc delete mode 100644 target/mips/kvm.c delete mode 100644 tcg/mips64/tcg-target.c.inc delete mode 100644 tests/docker/dockerfiles/debian-mips64el-cross.docker delete mode 100644 tests/docker/dockerfiles/debian-mipsel-cross.docker -- 2.53.0

2 9

Plans for 12.4.0 release (freeze on 2026-05-25)
by Jiri Denemark 18 May '26

18 May '26

We are getting close to 12.4.0 release of libvirt. To aim for the release on Monday 01 Jun I suggest entering the freeze on Monday 25 May and tagging RC2 on Thursday 28 May. I hope this works for everyone. Jirka

1 0