November 2024 - Devel - libvirt List Archives

Container build failures for cross-builds on debian-11
by Martin Kletzander 25 Nov '24

25 Nov '24

Weekly container builds fail for almost 2 months now (last passed container build was on 2nd of September) due to debian-11 being probably broken when installing cross-arch packages. Debian 12 was released at the 10th of June 2023, so we support debian-11 for 7 more months. But the cross-builds are probably going to fail for all those 7 months. Since that spoils the view of the pipelines I would suggest we remove the cross-architecture builds for debian-11 since we're still testing them on debian-12 and that works nicely. We would still keep x86_64 and i686 debian-11 builds there of course. Is anyone opposed to that or is there any clear issue with the above suggestion?

1 0

test branch of patches that use a "tc" filter to fixup UDP checksums
by Laine Stump 22 Nov '24

22 Nov '24

This branch uses tc to fixup the checksum. It's appearing to work with the few guests I've tested so far, but there is an issue when a network has <bandwidth> configured, and I don't want to post the patches for review until I figure that out. In the meantime anyone who wants to test with a non-<bandwidth> network, please do :-) https://gitlab.com/lainestump/libvirt/-/tree/network-freebsd-checksum-fix-t…

3 4

[PATCH 00/32] Add support for versioned CPU models
by Jiri Denemark 21 Nov '24

21 Nov '24

When parsing a domain XML which uses a non-versioned CPU model we want to replace it with the appropriate version variant similarly to what we do with machine types. Theoretically QEMU supports per machine type specification of a version with which a non-versioned CPU model is replaced, but this is always 1 for all machine types and the query-machines QMP command does not even report the value. Luckily after talking to Igor, having a single number per machine type does not really allow for setting it to anything but 1 as CPU models have different number of versions. Each machine type would need to define a specific version for each CPU model, which would be a maintenance nightmare. For this reason there's no desire to ever resolve non-versioned CPU models to anything but v1 in QEMU and the per machine type setting will most likely even be removed completely. Thus it is safe for us to always use v1 as the canonical CPU model. Some non-versioned CPU models, however, are actually aliases to specific versions of a base model rather than being base models themselves. These are the old CPU model variants before model versions were introduced, e.g., -noTSX, -IBRS, etc. The mapping of these names to versions is hardcoded and will never change. We do not translate such CPU models to the corresponding versioned names. This allows us to introduce the corresponding -v* variants that match the QEMU models rather than the existing definitions in our CPU map. The guest CPU will be the same either way, but the way libvirt checks the CPU model compatibility with the host will be different. The old "partial" check done by libvirt using the definition from CPU map will still be used for the old names (we can't change this for compatibility reasons), but the corresponding versioned variants (as well as all other versions that do not have a non-versioned alias) will benefit from the recently introduced new "partial" check which uses only the information we get from QEMU to check whether a specific CPU definition is usable on the host. Other I considered were: - replace -noTSX, -IBRS, ... models with their versioned variants - we'd need to translate them back for migration (just what we do for -v1) for backward compatibility - I found the benefit of new partial checking when explicitly using the versioned variants quite appealing and dropped the relevant changes in progress - do not translate anything, i.e., not even base models to -v1 - the idea behind translating was to make sure QEMU suddenly doesn't start translating the base CPU model to a different version (this does not happen with -noTSX etc. as they are hardcoded aliases); Igor said they will never do that so is this still valid? - not translating would bring the same benefit of explicitly using -v1 vs non-versioned name I guess the current mix does not look very consistent (i.e., it's not either all or nothing), but it makes sense to me. The question is whether it also makes sense to others :-) Jiri Denemark (32): cpu_x86: Copy added and removed features from ancestor sync_qemu_features_i386: Add some removed features back sync_qemu_models_i386: Use f-strings sync_qemu_models_i386: Do not overwrite existing models sync_qemu_models_i386: Do not require full path to QEMU's cpu.c sync_qemu_models_i386: Add support for versioned CPU models sync_qemu_models_i386: Store extra info in a separate file sync_qemu_models_i386: Switch to lxml cpu_map: Group models in index.xml sync_qemu_models_i386: Update index.xml sync_qemu_models_i386: Copy signatures from base model cpu: Introduce virCPUCheckModel qemu: Canonicalize CPU models cpu_map: Add versions of SierraForest CPU model cpu_map: Add versions of GraniteRapids CPU model cpu_map: Add versions of SapphireRapids CPU model cpu_map: Add versions of Snowridge CPU model cpu_map: Add versions of Cooperlake CPU model cpu_map: Add versions of Icelake-Server CPU model cpu_map: Add versions of Cascadelake-Server CPU model cpu_map: Add versions of Skylake-Server CPU model cpu_map: Add versions of Skylake-Client CPU model cpu_map: Add versions of Broadwell CPU model cpu_map: Add versions of Haswell CPU model cpu_map: Add versions of IvyBridge CPU model cpu_map: Add versions of SandyBridge CPU model cpu_map: Add versions of Westmere CPU model cpu_map: Add versions of Nehalem CPU model cpu_map: Add versions of EPYC-Milan CPU model cpu_map: Add versions of EPYC-Rome CPU model cpu_map: Add versions of EPYC CPU model cpu_map: Add versions of Dhyana CPU model src/cpu/cpu.c | 25 + src/cpu/cpu.h | 8 + src/cpu/cpu_map.c | 2 +- src/cpu/cpu_x86.c | 40 +- src/cpu_map/index.xml | 286 ++-- src/cpu_map/meson.build | 60 + src/cpu_map/sync_qemu_features_i386.py | 3 + src/cpu_map/sync_qemu_models_i386.py | 178 ++- src/cpu_map/x86_Broadwell-v1.xml | 6 + src/cpu_map/x86_Broadwell-v2.xml | 140 ++ src/cpu_map/x86_Broadwell-v3.xml | 143 ++ src/cpu_map/x86_Broadwell-v4.xml | 141 ++ src/cpu_map/x86_Cascadelake-Server-v1.xml | 6 + src/cpu_map/x86_Cascadelake-Server-v2.xml | 157 +++ src/cpu_map/x86_Cascadelake-Server-v3.xml | 155 +++ src/cpu_map/x86_Cascadelake-Server-v4.xml | 156 +++ src/cpu_map/x86_Cascadelake-Server-v5.xml | 158 +++ src/cpu_map/x86_Cooperlake-v1.xml | 6 + src/cpu_map/x86_Cooperlake-v2.xml | 164 +++ src/cpu_map/x86_Dhyana-v1.xml | 6 + src/cpu_map/x86_Dhyana-v2.xml | 73 ++ src/cpu_map/x86_EPYC-Milan-v1.xml | 6 + src/cpu_map/x86_EPYC-Milan-v2.xml | 99 ++ src/cpu_map/x86_EPYC-Rome-v1.xml | 6 + src/cpu_map/x86_EPYC-Rome-v2.xml | 86 ++ src/cpu_map/x86_EPYC-Rome-v3.xml | 86 ++ src/cpu_map/x86_EPYC-Rome-v4.xml | 85 ++ src/cpu_map/x86_EPYC-v1.xml | 6 + src/cpu_map/x86_EPYC-v2.xml | 75 ++ src/cpu_map/x86_EPYC-v3.xml | 79 ++ src/cpu_map/x86_EPYC-v4.xml | 79 ++ src/cpu_map/x86_GraniteRapids-v1.xml | 6 + src/cpu_map/x86_Haswell-v1.xml | 6 + src/cpu_map/x86_Haswell-v2.xml | 134 ++ src/cpu_map/x86_Haswell-v3.xml | 137 ++ src/cpu_map/x86_Haswell-v4.xml | 135 ++ src/cpu_map/x86_Icelake-Server-v1.xml | 6 + src/cpu_map/x86_Icelake-Server-v2.xml | 158 +++ src/cpu_map/x86_Icelake-Server-v3.xml | 165 +++ src/cpu_map/x86_Icelake-Server-v4.xml | 172 +++ src/cpu_map/x86_Icelake-Server-v5.xml | 174 +++ src/cpu_map/x86_Icelake-Server-v6.xml | 175 +++ src/cpu_map/x86_Icelake-Server-v7.xml | 177 +++ src/cpu_map/x86_IvyBridge-v1.xml | 6 + src/cpu_map/x86_IvyBridge-v2.xml | 119 ++ src/cpu_map/x86_Nehalem-v1.xml | 6 + src/cpu_map/x86_Nehalem-v2.xml | 101 ++ src/cpu_map/x86_SandyBridge-v1.xml | 6 + src/cpu_map/x86_SandyBridge-v2.xml | 110 ++ src/cpu_map/x86_SapphireRapids-v1.xml | 6 + src/cpu_map/x86_SapphireRapids-v2.xml | 193 +++ src/cpu_map/x86_SapphireRapids-v3.xml | 198 +++ src/cpu_map/x86_SierraForest-v1.xml | 6 + src/cpu_map/x86_Skylake-Client-v1.xml | 6 + src/cpu_map/x86_Skylake-Client-v2.xml | 141 ++ src/cpu_map/x86_Skylake-Client-v3.xml | 139 ++ src/cpu_map/x86_Skylake-Client-v4.xml | 141 ++ src/cpu_map/x86_Skylake-Server-v1.xml | 6 + src/cpu_map/x86_Skylake-Server-v2.xml | 149 +++ src/cpu_map/x86_Skylake-Server-v3.xml | 147 +++ src/cpu_map/x86_Skylake-Server-v4.xml | 148 +++ src/cpu_map/x86_Skylake-Server-v5.xml | 150 +++ src/cpu_map/x86_Snowridge-v1.xml | 6 + src/cpu_map/x86_Snowridge-v2.xml | 143 ++ src/cpu_map/x86_Snowridge-v3.xml | 145 +++ src/cpu_map/x86_Snowridge-v4.xml | 143 ++ src/cpu_map/x86_Westmere-v1.xml | 6 + src/cpu_map/x86_Westmere-v2.xml | 105 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 53 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_domain.c | 6 + src/qemu/qemu_postparse.c | 19 + .../x86_64-cpuid-Atom-P5362-json.xml | 75 +- .../x86_64-cpuid-Core-i7-8550U-json.xml | 72 +- .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +- .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 9 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +- .../x86_64-cpuid-EPYC-7601-32-Core-json.xml | 6 +- ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 6 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 9 +- ...64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml | 6 +- .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 79 +- ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 84 +- .../x86_64-cpuid-baseline-EPYC+Rome.xml | 6 +- .../x86_64-cpuid-baseline-Ryzen+Rome.xml | 6 +- .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 369 ++++++ .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 740 ++++++++++- tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 369 ++++++ .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 382 ++++++ .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 798 +++++++++++- tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 382 ++++++ .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 476 +++++++ .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1003 +++++++++++++- tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 476 +++++++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 483 +++++++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 1008 +++++++++++++- tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 483 +++++++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 509 ++++++++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1018 ++++++++++++++- tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 509 ++++++++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 509 ++++++++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1154 +++++++++++++++-- tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 509 ++++++++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 509 ++++++++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 830 +++++++++++- .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 830 +++++++++++- tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 509 ++++++++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 550 ++++++++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 862 +++++++++++- tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 550 ++++++++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 864 +++++++++++- tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 848 +++++++++++- tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 811 +++++++++++- tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 711 +++++++++- .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 816 +++++++++++- .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1099 ++++++++++++++-- tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 816 +++++++++++- .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 816 +++++++++++- .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1099 ++++++++++++++-- tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 816 +++++++++++- .../cpu-Haswell.x86_64-latest.args | 2 +- .../cpu-Haswell.x86_64-latest.xml | 2 +- .../cpu-Haswell2.x86_64-latest.args | 2 +- .../cpu-Haswell2.x86_64-latest.xml | 2 +- .../cpu-Haswell3.x86_64-latest.args | 2 +- .../cpu-Haswell3.x86_64-latest.xml | 2 +- ...-Icelake-Server-pconfig.x86_64-latest.args | 2 +- ...u-Icelake-Server-pconfig.x86_64-latest.xml | 2 +- .../cpu-fallback.x86_64-8.0.0.args | 2 +- .../cpu-fallback.x86_64-8.0.0.xml | 2 +- ...-host-model-fallback-kvm.x86_64-8.1.0.args | 2 +- ...host-model-fallback-kvm.x86_64-latest.args | 2 +- ...host-model-fallback-tcg.x86_64-latest.args | 2 +- ...cpu-host-model-features.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-8.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...ost-model-nofallback-kvm.x86_64-8.1.0.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- ...st-model-nofallback-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-tcg.x86_64-latest.args | 2 +- .../cpu-nofallback.x86_64-8.0.0.args | 2 +- .../cpu-nofallback.x86_64-8.0.0.xml | 2 +- .../cpu-strict1.x86_64-latest.args | 2 +- .../cpu-strict1.x86_64-latest.xml | 2 +- .../cpu-translation.x86_64-latest.args | 2 +- .../cpu-translation.x86_64-latest.xml | 2 +- 154 files changed, 33779 insertions(+), 1095 deletions(-) create mode 100644 src/cpu_map/x86_Broadwell-v1.xml create mode 100644 src/cpu_map/x86_Broadwell-v2.xml create mode 100644 src/cpu_map/x86_Broadwell-v3.xml create mode 100644 src/cpu_map/x86_Broadwell-v4.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v1.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v3.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Cooperlake-v1.xml create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml create mode 100644 src/cpu_map/x86_Dhyana-v1.xml create mode 100644 src/cpu_map/x86_Dhyana-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Milan-v1.xml create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v1.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml create mode 100644 src/cpu_map/x86_EPYC-v1.xml create mode 100644 src/cpu_map/x86_EPYC-v2.xml create mode 100644 src/cpu_map/x86_EPYC-v3.xml create mode 100644 src/cpu_map/x86_EPYC-v4.xml create mode 100644 src/cpu_map/x86_GraniteRapids-v1.xml create mode 100644 src/cpu_map/x86_Haswell-v1.xml create mode 100644 src/cpu_map/x86_Haswell-v2.xml create mode 100644 src/cpu_map/x86_Haswell-v3.xml create mode 100644 src/cpu_map/x86_Haswell-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v1.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v2.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v7.xml create mode 100644 src/cpu_map/x86_IvyBridge-v1.xml create mode 100644 src/cpu_map/x86_IvyBridge-v2.xml create mode 100644 src/cpu_map/x86_Nehalem-v1.xml create mode 100644 src/cpu_map/x86_Nehalem-v2.xml create mode 100644 src/cpu_map/x86_SandyBridge-v1.xml create mode 100644 src/cpu_map/x86_SandyBridge-v2.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v1.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v3.xml create mode 100644 src/cpu_map/x86_SierraForest-v1.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v1.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v2.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v3.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v1.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v2.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v3.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml create mode 100644 src/cpu_map/x86_Snowridge-v1.xml create mode 100644 src/cpu_map/x86_Snowridge-v2.xml create mode 100644 src/cpu_map/x86_Snowridge-v3.xml create mode 100644 src/cpu_map/x86_Snowridge-v4.xml create mode 100644 src/cpu_map/x86_Westmere-v1.xml create mode 100644 src/cpu_map/x86_Westmere-v2.xml -- 2.47.0

2 56

[libvirt PATCH] docs: document external swtpm
by Ján Tomko 21 Nov '24

21 Nov '24

When external swtpm support was added back in 9.0.0, I omitted the update of the XML docs. Add it now, especially since the 'emulator' backend can now also use the <source> element. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- docs/formatdomain.rst | 43 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 7 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index b3f9f453aa..a5510e82f5 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -8140,6 +8140,20 @@ Example: usage of the TPM Emulator </devices> ... +Example: usage of external TPM emulator :since:`Since 9.0.0` + +:: + + ... + <devices> + <tpm model='tpm-tis'> + <backend type='external'> + <source type='unix' mode='connect' path='/tmp/path.sock'/> + </backend> + </tpm> + </devices> + ... + ``model`` The ``model`` attribute specifies what device model QEMU provides to the guest. If no model name is provided, ``tpm-tis`` will automatically be chosen @@ -8178,6 +8192,12 @@ Example: usage of the TPM Emulator parameter can be used to enable logging in the emulator backend, and accepts non-zero integer values. + ``external`` + For this backend, libvirt expects the TPM emulator to be started externally. + The path to the unix socket where the emulator is listening is passed + via the ``source`` element. Other ``backend`` sub-elements do not apply + in these case, since they are controlled by the emulator command line. + ``version`` The ``version`` attribute indicates the version of the TPM. This attribute only works with the ``emulator`` backend. The following versions are @@ -8190,8 +8210,13 @@ Example: usage of the TPM Emulator architecture, TPM model and backend. ``source`` - The ``source`` element specifies the location of the TPM state storage . This - element only works with the ``emulator`` backend. + For the ``emulator`` backend, the ``source`` element specifies the location + of the TPM state storage. :since:`Since v10.10.0` + + For the ``external`` backend, it specifies the socket of the externally + run TPM emulator. :since:`Since v9.0.0` + + This element does not work with the ``passthrough`` backend. When specified, it is the user's responsability to prevent files from being used by multiple VMs or emulators (swtpm will also use advisory locking). If @@ -8202,14 +8227,18 @@ Example: usage of the TPM Emulator The following attributes are supported: ``type`` - The type of storage. It's possible to provide "file" to utilize a single - file or block device where the TPM state will be stored, or "dir" for the - directory where the files will be stored. + For ``external`` backend, only type ``unix`` is supported. + For ``emulator`` backend, it's possible to provide ``file`` to utilize + a single file or block device where the TPM state will be stored, + or ``dir`` for the directory where the files will be stored. + + ``mode`` + Connection mode for the ``unix`` socket. Only ``connect`` is supported. + Can be omitted. ``path`` - The path to the TPM state storage. + The path to the TPM state storage, or the unix socket. - :since:`Since v10.10.0` ``persistent_state`` The ``persistent_state`` attribute indicates whether 'swtpm' TPM state is -- 2.47.0

2 1

[PATCH] QEMU: allow to hot plugging virtio-serial-pci device
by shenjiatong 21 Nov '24

21 Nov '24

Virtio-serial-pci device is hot pluggable, losen the restriction and allow user to hot plug it. --- src/qemu/qemu_hotplug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index bddd553c88..55512476e4 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -837,7 +837,8 @@ qemuDomainAttachControllerDevice(virDomainObj *vm, { .controller = controller } }; bool releaseaddr = false; - if (controller->type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI) { + if (controller->type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI && \ + controller->type != VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("'%1$s' controller cannot be hot plugged."), virDomainControllerTypeToString(controller->type)); -- 2.43.0

3 3

[PATCH 0/4] qemu: Adapt to deprecation of 'reconnect' field for 'stream 'netdevs' and update qemu capablities
by Peter Krempa 19 Nov '24

19 Nov '24

Peter Krempa (4): qemu: capabilities: Restore grouping in 'virQEMUCapsQMPSchemaQueries' qemu: capabilities: Introduce QEMU_CAPS_NETDEV_STREAM_RECONNECT_MILISECONDS qemu: passt: Use 'reconnect-ms' instead of 'reconnect' with new qemus tests: qemucapabilitiesdata: Update 'x86_64' capabilities for the qemu-9.2 dev cycle src/qemu/qemu_capabilities.c | 18 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_passt.c | 14 +- .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64.replies | 4407 +++++++++-------- .../caps_9.2.0_x86_64.xml | 310 +- .../net-user-passt.x86_64-latest.args | 2 +- 7 files changed, 2523 insertions(+), 2230 deletions(-) -- 2.47.0

2 6

[PATCH 0/4] Add news for recent features and CVEs
by Han Han 19 Nov '24

19 Nov '24

Han Han (4): NEWS: qemu: Add support for hyperv enlightenments features NEWS: cpu_map: Add the EPYC-Genoa cpu mode NEWS: Add the news for CVE-2024-2494 NEWS: Add the news for CVE-2024-4418 NEWS.rst | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) -- 2.47.0

2 5

[PATCH v2] qemuDomainDiskChangeSupported: Add missing iothreads check
by Peter Krempa 19 Nov '24

19 Nov '24

From: Adam Julis <ajulis(a)redhat.com> GSList of iothreads is not allowed to be changed while the virtual machine is running. Resolves: https://issues.redhat.com/browse/RHEL-23607 Signed-off-by: Adam Julis <ajulis(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Changes to v1: - extrac to separate function - improve readability of loops and handling of error - fix possibility of infinitely looping if first queue of both queue lists matches src/qemu/qemu_domain.c | 46 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 66ab4baa8b..153bd56e86 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -6591,6 +6591,49 @@ qemuDomainStorageSourceAccessAllow(virQEMUDriver *driver, } +static bool +qemuDomainDiskChangeSupportedIothreads(virDomainDiskDef *disk, + virDomainDiskDef *orig_disk) +{ + GSList *old = orig_disk->iothreads; + GSList *new = disk->iothreads; + + while (true) { + virDomainDiskIothreadDef *old_def; + virDomainDiskIothreadDef *new_def; + size_t i; + + /* match - both empty or both at the end */ + if (!old && !new) + return true; + + /* mismatched length of lists */ + if (!old || !new) + goto fail; + + old_def = old->data; + new_def = new->data; + + if (old_def->id != new_def->id || + old_def->nqueues != new_def->nqueues) + goto fail; + + for (i = 0; i < old_def->nqueues; i++) { + if (old_def->queues[i] != new_def->queues[i]) + goto fail; + } + + new = new->next; + old = old->next; + } + + fail: + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("cannot modify field '<iothreads>' (or it's parts) of the disk")); + return false; +} + + /* * Makes sure the @disk differs from @orig_disk only by the source * path and nothing else. Fields that are being checked and the @@ -6735,6 +6778,9 @@ qemuDomainDiskChangeSupported(virDomainDiskDef *disk, CHECK_EQ(discard, "discard", true); CHECK_EQ(iothread, "iothread", true); + if (!qemuDomainDiskChangeSupportedIothreads(disk, orig_disk)) + return false; + CHECK_STREQ_NULLABLE(domain_name, "backenddomain"); -- 2.47.0

2 1

Plans for 10.10.0 release (freeze on Tuesday 26 Nov)
by Jiri Denemark 19 Nov '24

19 Nov '24

We are getting close to 10.10.0 release of libvirt. To aim for the release on Monday 02 Dec I suggest entering the freeze on Tuesday 26 Nov and tagging RC2 on Thursday 28 Nov. I hope this works for everyone. Jirka

1 0

[PATCH] qemuDomainDiskChangeSupported: Add missing iothreads check
by Adam Julis 18 Nov '24

18 Nov '24

GSList of iothreads is not allowed to be changed while the virtual machine is running. Resolves: https://issues.redhat.com/browse/RHEL-23607 Signed-off-by: Adam Julis <ajulis(a)redhat.com> --- While the qemuDomainDiskChangeSupported() design primarily uses its macros (CHECK_EQ and CHECK_STREQ_NULLABLE), the logic for comparing 2 GSList of iothreads could perhaps be extracted into a separate function (e.g. IothreadsGslistCompare(GSList *first, GSList *second)). I am absolutely not sure about this idea so feel free to comment. src/qemu/qemu_domain.c | 53 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 298f4bfb9e..2b5222c685 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8505,6 +8505,59 @@ qemuDomainDiskChangeSupported(virDomainDiskDef *disk, CHECK_EQ(discard, "discard", true); CHECK_EQ(iothread, "iothread", true); + /* compare list of iothreads, no change allowed */ + if (orig_disk->iothreads != disk->iothreads) { + GSList *old; + GSList *new = disk->iothreads; + bool print_err = true; + + for (old = orig_disk->iothreads; old; old = old->next) { + virDomainDiskIothreadDef *orig = old->data; + virDomainDiskIothreadDef *update; + print_err = false; + + if (new == NULL) { + print_err = true; + break; + } + + update = new->data; + + if (orig->id != update->id) { + print_err = true; + break; + } + + if (orig->nqueues != update->nqueues) { + print_err = true; + break; + } + + if (orig->nqueues != 0) { + ssize_t i = 0; + + while (i < orig->nqueues) { + if (orig->queues[i] != update->queues[i]) { + print_err = true; + break; + } + } + } + + new = new->next; + if (new) + print_err = true; + } + + if (print_err) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("cannot modify field '%1$s' (or it's parts) of the disk"), + "iothreads"); + return false; + } + } + + CHECK_STREQ_NULLABLE(domain_name, "backenddomain"); -- 2.45.2

3 2