- Devel - libvirt List Archives

[PATCH 0/2] ch_monitor: Two simple improvements
by Michal Privoznik 11 Nov '24

11 Nov '24

I've noticed these why reviewing some other CH patches on the list. Michal Prívozník (2): ch_monitor: Avoid possible double free in virCHMonitorClose() ch_monitor: Report OS error when removing socket fails src/ch/ch_monitor.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) -- 2.45.2

2 3

[PATCH v2 0/4] Full boot order support on s390x
by Boris Fiuczynski 11 Nov '24

11 Nov '24

This series adds on s390x full boot order support which has been introduced recently in QEMU with the PR https://lore.kernel.org/qemu-devel/20241023131710.906748-1-thuth@redhat.com/ Changes in v2: - fixed up patch 2 with Peter's feedback - added RBs given - added NEWS update The replies and xml files are removed from patch 2 in this series and are available in https://gitlab.com/fiuczy/libvirt/-/commits/fullbootorder Boris Fiuczynski (4): qemu: capabilities: Add QEMU_CAPS_VIRTIO_CCW_DEVICE_LOADPARM tests: add capabilities for QEMU 9.2.0 on s390x qemu: command: add multi boot device support on s390x NEWS: qemu: add multi boot device support on s390x NEWS.rst | 16 + src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 36 +- src/qemu/qemu_command.h | 6 +- src/qemu/qemu_hotplug.c | 6 +- tests/domaincapsdata/qemu_9.2.0.s390x.xml | 311 + .../caps_5.2.0_s390x.replies | 321 +- .../caps_6.0.0_s390x.replies | 321 +- .../caps_8.1.0_s390x.replies | 321 +- .../caps_8.2.0_s390x.replies | 321 +- .../caps_9.1.0_s390x.replies | 321 +- .../caps_9.2.0_s390x.replies | 36741 ++++++++++++++++ .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 3752 ++ .../machine-loadparm-hostdev.s390x-9.1.0.args | 33 + .../machine-loadparm-hostdev.s390x-9.1.0.xml | 33 + ...machine-loadparm-hostdev.s390x-latest.args | 4 +- ...-multiple-disks-nets-s390.s390x-9.1.0.args | 40 + ...m-multiple-disks-nets-s390.s390x-9.1.0.xml | 51 + ...multiple-disks-nets-s390.s390x-latest.args | 8 +- ...machine-loadparm-net-s390.s390x-9.1.0.args | 34 + .../machine-loadparm-net-s390.s390x-9.1.0.xml | 32 + ...achine-loadparm-net-s390.s390x-latest.args | 4 +- .../machine-loadparm-s390.s390x-9.1.0.args | 34 + .../machine-loadparm-s390.s390x-9.1.0.xml | 33 + .../machine-loadparm-s390.s390x-latest.args | 4 +- tests/qemuxmlconftest.c | 4 + 27 files changed, 42676 insertions(+), 120 deletions(-) create mode 100644 tests/domaincapsdata/qemu_9.2.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml create mode 100644 tests/qemuxmlconfdata/machine-loadparm-hostdev.s390x-9.1.0.args create mode 100644 tests/qemuxmlconfdata/machine-loadparm-hostdev.s390x-9.1.0.xml create mode 100644 tests/qemuxmlconfdata/machine-loadparm-multiple-disks-nets-s390.s390x-9.1.0.args create mode 100644 tests/qemuxmlconfdata/machine-loadparm-multiple-disks-nets-s390.s390x-9.1.0.xml create mode 100644 tests/qemuxmlconfdata/machine-loadparm-net-s390.s390x-9.1.0.args create mode 100644 tests/qemuxmlconfdata/machine-loadparm-net-s390.s390x-9.1.0.xml create mode 100644 tests/qemuxmlconfdata/machine-loadparm-s390.s390x-9.1.0.args create mode 100644 tests/qemuxmlconfdata/machine-loadparm-s390.s390x-9.1.0.xml -- 2.45.0

3 11

[PATCH 00/13] qemu: NVRAM template handling fixes and support for block device backed NVRAM
by Peter Krempa 11 Nov '24

11 Nov '24

This patch fixes a few quirks regarding block device use for NVRAM backing and introduces support for populating the block device from template. Peter Krempa (13): qemuPrepareNVRAM: Don't attempt to create NVRAM on block device qemuFirmwareEnsureNVRAM: Don't try to setup non-local nvram qemu: Install backing store terminators for 'pflash' blockdevs conf: domain: Clarify nvram/loader format logic docs: formatdomain: Clarify that NVRAM template is also being autoselected firmware: Add 'templateFormat' XML attribute and plumb it in conf: domain: Output 'format' attribute of '<nvram>' also for' raw images conf: Always format firmware image format qemuPrepareNVRAM: Refuse conversion of NVRAM backing file format qemuFirmwareMatchDomain: Don't base firmware selection on nvram image format conf: Remove nonsensical requirement of nvram format matching firmware format qemu: process: Extract setup of file-backed nvram from template qemu: process: Introduce setup of block-device backed NVRAM docs/formatdomain.rst | 22 +-- src/conf/domain_conf.c | 62 +++++---- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 17 ++- src/qemu/qemu_domain.c | 2 + src/qemu/qemu_firmware.c | 47 ++++--- src/qemu/qemu_process.c | 127 +++++++++++++++--- .../aarch64-virt-graphics.aarch64-latest.xml | 4 +- ...ch64-virt-headless-mmio.aarch64-latest.xml | 4 +- .../aarch64-virt-headless.aarch64-latest.xml | 4 +- ...ware-auto-bios-stateless.x86_64-latest.xml | 2 +- .../firmware-auto-bios.x86_64-latest.xml | 2 +- ...efi-aarch64.aarch64-latest.abi-update.args | 4 +- ...-efi-aarch64.aarch64-latest.abi-update.xml | 2 +- ...rmware-auto-efi-aarch64.aarch64-latest.xml | 4 +- ...e-auto-efi-enrolled-keys.x86_64-latest.xml | 4 +- ...loader-qcow2-nvram-path.x86_64-latest.args | 4 +- ...-loader-qcow2-nvram-path.x86_64-latest.xml | 2 +- ...efi-format-loader-qcow2.x86_64-latest.args | 4 +- ...-efi-format-loader-qcow2.x86_64-latest.xml | 2 +- ...t-loader-raw.aarch64-latest.abi-update.xml | 4 +- ...o-efi-format-loader-raw.aarch64-latest.xml | 4 +- ...uto-efi-format-mismatch.x86_64-latest.args | 37 +++++ ...auto-efi-format-mismatch.x86_64-latest.err | 1 - ...auto-efi-format-mismatch.x86_64-latest.xml | 41 ++++++ .../firmware-auto-efi-format-mismatch.xml | 4 +- ...nvram-qcow2-network-nbd.x86_64-latest.args | 6 +- ...-nvram-qcow2-network-nbd.x86_64-latest.xml | 2 +- ...uto-efi-format-nvram-qcow2-network-nbd.xml | 2 +- ...format-nvram-qcow2-path.x86_64-latest.args | 4 +- ...-format-nvram-qcow2-path.x86_64-latest.xml | 2 +- ...-efi-format-nvram-qcow2.x86_64-latest.args | 4 +- ...o-efi-format-nvram-qcow2.x86_64-latest.xml | 2 +- ...auto-efi-loader-insecure.x86_64-latest.xml | 4 +- ...-loader-path-nonstandard.x86_64-latest.xml | 2 +- ...are-auto-efi-loader-path.x86_64-latest.xml | 4 +- ...oader-secure.x86_64-latest.abi-update.args | 4 +- ...loader-secure.x86_64-latest.abi-update.xml | 2 +- ...e-auto-efi-loader-secure.x86_64-latest.xml | 4 +- ...ngarch64.loongarch64-latest.abi-update.xml | 4 +- ...uto-efi-loongarch64.loongarch64-latest.xml | 4 +- ...uto-efi-no-enrolled-keys.x86_64-latest.xml | 4 +- ...ware-auto-efi-no-secboot.x86_64-latest.xml | 4 +- ...ware-auto-efi-nvram-file.x86_64-latest.xml | 4 +- ...-efi-nvram-network-iscsi.x86_64-latest.xml | 4 +- ...to-efi-nvram-network-nbd.x86_64-latest.xml | 4 +- ...ware-auto-efi-nvram-path.x86_64-latest.xml | 4 +- ...ram-template-nonstandard.x86_64-latest.xml | 2 +- ...-auto-efi-nvram-template.x86_64-latest.xml | 4 +- ...efi-riscv64.riscv64-latest.abi-update.args | 4 +- ...-efi-riscv64.riscv64-latest.abi-update.xml | 2 +- ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 2 +- .../firmware-auto-efi-rw.x86_64-latest.xml | 2 +- ...irmware-auto-efi-secboot.x86_64-latest.xml | 4 +- ...irmware-auto-efi-smm-off.x86_64-latest.xml | 4 +- ...mware-auto-efi-stateless.x86_64-latest.xml | 2 +- ...are-auto-efi.x86_64-latest.abi-update.args | 4 +- ...ware-auto-efi.x86_64-latest.abi-update.xml | 2 +- .../firmware-auto-efi.x86_64-latest.xml | 4 +- ...re-manual-bios-stateless.x86_64-latest.xml | 2 +- .../firmware-manual-bios.x86_64-latest.xml | 2 +- ...fi-aarch64-legacy-paths.aarch64-latest.xml | 4 +- ...manual-efi-acpi-aarch64.aarch64-latest.xml | 4 +- ...ware-manual-efi-acpi-q35.x86_64-latest.xml | 4 +- ...ware-manual-efi-features.x86_64-latest.xml | 4 +- ...-loader-path-nonstandard.x86_64-latest.xml | 4 +- ...manual-efi-loader-secure.x86_64-latest.xml | 4 +- ...rolled-keys-legacy-paths.x86_64-latest.xml | 4 +- ...ual-efi-no-enrolled-keys.x86_64-latest.xml | 4 +- ...-no-secboot-legacy-paths.x86_64-latest.xml | 4 +- ...re-manual-efi-no-secboot.x86_64-latest.xml | 4 +- ...nual-efi-noacpi-aarch64.aarch64-latest.xml | 4 +- ...re-manual-efi-nvram-file.x86_64-latest.xml | 4 +- ...-efi-nvram-network-iscsi.x86_64-latest.xml | 4 +- ...al-efi-nvram-network-nbd.x86_64-latest.xml | 4 +- ...ram-template-nonstandard.x86_64-latest.xml | 4 +- ...anual-efi-nvram-template.x86_64-latest.xml | 4 +- ...e-manual-efi-rw-implicit.x86_64-latest.xml | 2 +- ...nual-efi-rw-legacy-paths.x86_64-latest.xml | 2 +- ...nual-efi-rw-modern-paths.x86_64-latest.xml | 2 +- .../firmware-manual-efi-rw.x86_64-latest.xml | 2 +- ...efi-secboot-legacy-paths.x86_64-latest.xml | 4 +- ...mware-manual-efi-secboot.x86_64-latest.xml | 4 +- ...are-manual-efi-stateless.x86_64-latest.xml | 2 +- .../firmware-manual-efi.x86_64-latest.xml | 4 +- ...f-aarch64-virt-headless.aarch64-latest.xml | 4 +- .../hvf-x86_64-q35-headless.x86_64-latest.xml | 4 +- .../pvpanic-pci-aarch64.aarch64-latest.xml | 4 +- ...-pci-no-address-aarch64.aarch64-latest.xml | 4 +- .../virtio-iommu-aarch64.aarch64-latest.xml | 4 +- tests/qemuxmlconftest.c | 2 +- .../test-disk-positional-parms-full.xml | 2 +- .../test-disk-positional-parms-partial.xml | 2 +- tests/xlconfigdata/test-disk-qed.xml | 2 +- .../xlconfigdata/test-fullvirt-acpi-slic.xml | 2 +- tests/xlconfigdata/test-fullvirt-cpuid.xml | 2 +- ...ullvirt-direct-kernel-boot-bogus-extra.xml | 2 +- ...test-fullvirt-direct-kernel-boot-extra.xml | 2 +- .../test-fullvirt-direct-kernel-boot.xml | 2 +- .../xlconfigdata/test-fullvirt-hpet-timer.xml | 2 +- .../test-fullvirt-hypervisor-features.xml | 2 +- .../test-fullvirt-multi-timer.xml | 2 +- .../test-fullvirt-multiserial.xml | 2 +- tests/xlconfigdata/test-fullvirt-multiusb.xml | 2 +- .../test-fullvirt-nestedhvm-disabled.xml | 2 +- .../xlconfigdata/test-fullvirt-nestedhvm.xml | 2 +- tests/xlconfigdata/test-fullvirt-nohap.xml | 2 +- tests/xlconfigdata/test-fullvirt-ovmf.xml | 2 +- .../test-fullvirt-ovswitch-tagged.xml | 2 +- .../test-fullvirt-ovswitch-trunked.xml | 2 +- tests/xlconfigdata/test-fullvirt-pci.xml | 2 +- .../xlconfigdata/test-fullvirt-tsc-timer.xml | 2 +- tests/xlconfigdata/test-fullvirt-type.xml | 2 +- tests/xlconfigdata/test-fullvirt-vnuma.xml | 2 +- tests/xlconfigdata/test-net-fakemodel.xml | 2 +- tests/xlconfigdata/test-new-disk.xml | 2 +- tests/xlconfigdata/test-qemu-passthrough.xml | 2 +- .../test-rbd-multihost-noauth.xml | 2 +- tests/xlconfigdata/test-spice-features.xml | 2 +- tests/xlconfigdata/test-spice.xml | 2 +- tests/xlconfigdata/test-vif-multi-ip.xml | 2 +- tests/xlconfigdata/test-vif-rate.xml | 2 +- tests/xlconfigdata/test-vif-typename.xml | 2 +- tests/xmconfigdata/test-escape-paths.xml | 2 +- .../test-fullvirt-default-feature.xml | 2 +- .../xmconfigdata/test-fullvirt-force-hpet.xml | 2 +- .../test-fullvirt-force-nohpet.xml | 2 +- .../xmconfigdata/test-fullvirt-localtime.xml | 2 +- .../test-fullvirt-net-netfront.xml | 2 +- .../xmconfigdata/test-fullvirt-new-cdrom.xml | 2 +- tests/xmconfigdata/test-fullvirt-nohap.xml | 2 +- .../test-fullvirt-parallel-tcp.xml | 2 +- .../test-fullvirt-serial-file.xml | 2 +- .../test-fullvirt-serial-null.xml | 2 +- .../test-fullvirt-serial-pipe.xml | 2 +- .../xmconfigdata/test-fullvirt-serial-pty.xml | 2 +- .../test-fullvirt-serial-stdio.xml | 2 +- .../test-fullvirt-serial-tcp-telnet.xml | 2 +- .../xmconfigdata/test-fullvirt-serial-tcp.xml | 2 +- .../xmconfigdata/test-fullvirt-serial-udp.xml | 2 +- .../test-fullvirt-serial-unix.xml | 2 +- tests/xmconfigdata/test-fullvirt-sound.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbmouse.xml | 2 +- .../xmconfigdata/test-fullvirt-usbtablet.xml | 2 +- tests/xmconfigdata/test-fullvirt-utc.xml | 2 +- tests/xmconfigdata/test-no-source-cdrom.xml | 2 +- tests/xmconfigdata/test-pci-dev-syntax.xml | 2 +- tests/xmconfigdata/test-pci-devs.xml | 2 +- 148 files changed, 481 insertions(+), 266 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch.x86_64-latest.xml -- 2.47.0

3 16

[PATCH 0/3] Do not try hot(un)plugging platform char devices
by Martin Kletzander 11 Nov '24

11 Nov '24

Just don't. Martin Kletzander (3): qemu: Expose qemuChrIsPlatformDevice outside from qemu_command qemu_hotplug: Report better error message for platform serial devices qemu_hotplug: Do not report error for hot-unplugging non-existing device src/qemu/qemu_command.c | 2 +- src/qemu/qemu_command.h | 5 +++++ src/qemu/qemu_hotplug.c | 13 +++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-) -- 2.47.0

2 7

[PATCH v2 00/16] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé 08 Nov '24

08 Nov '24

Since v1: - Make device endianness configurable (Edgar) - Convert more Xilinx devices - Avoid preprocessor #if (Richard) - Add R-b tags Make machines endianness-agnostic, allowing to run a big-endian vCPU on the little-endian 'qemu-system-microblazeel' binary, and a little endian one on the big-endian 'qemu-system-microblaze' binary. Tests added, following combinations covered: - little-endian vCPU using little-endian binary (in-tree) - little-endian vCPU using big-endian binary (new) - big-endian vCPU using little-endian binary (new) - big-endian vCPU using big-endian binary (in-tree) To make a target endian-agnostic we need to remove the MO_TE uses. In order to do that, we propagate the MemOp from earlier in the call stack, or we extract it from the vCPU env (on MicroBlaze the CPU endianness is exposed by the 'ENDI' bit). Next step: Look at unifying binaries. Please review, Phil. Philippe Mathieu-Daudé (16): hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit hw/microblaze: Propagate CPU endianness to microblaze_load_kernel() hw/intc/xilinx_intc: Make device endianness configurable RFC hw/net/xilinx_ethlite: Simplify by having configurable endianness RFC hw/timer/xilinx_timer: Allow down to 8-bit memory access hw/timer/xilinx_timer: Make device endianness configurable hw/char/xilinx_uartlite: Make device endianness configurable hw/ssi/xilinx_spi: Make device endianness configurable hw/ssi/xilinx_spips: Make device endianness configurable target/microblaze: Explode MO_TExx -> MO_TE | MO_xx target/microblaze: Set MO_TE once in do_load() / do_store() target/microblaze: Introduce mo_endian() helper target/microblaze: Consider endianness while translating code hw/microblaze: Support various endianness for s3adsp1800 machines tests/functional: Explicit endianness of microblaze assets tests/functional: Add microblaze cross-endianness tests hw/microblaze/boot.h | 4 +- include/hw/ssi/xilinx_spips.h | 1 + target/microblaze/cpu.h | 7 +++ hw/arm/xilinx_zynq.c | 1 + hw/arm/xlnx-zynqmp.c | 4 ++ hw/char/xilinx_uartlite.c | 40 +++++++++---- hw/intc/xilinx_intc.c | 59 +++++++++++++++---- hw/microblaze/boot.c | 8 +-- hw/microblaze/petalogix_ml605_mmu.c | 4 +- hw/microblaze/petalogix_s3adsp1800_mmu.c | 59 ++++++++++++++++--- hw/microblaze/xlnx-zynqmp-pmu.c | 2 +- hw/net/xilinx_ethlite.c | 52 ++++++++++++---- hw/ppc/virtex_ml507.c | 1 + hw/ssi/xilinx_spi.c | 29 ++++++--- hw/ssi/xilinx_spips.c | 46 +++++++++++---- hw/timer/xilinx_timer.c | 42 ++++++++++--- target/microblaze/translate.c | 49 +++++++++------ .../functional/test_microblaze_s3adsp1800.py | 27 ++++++++- .../test_microblazeel_s3adsp1800.py | 25 +++++++- 19 files changed, 358 insertions(+), 102 deletions(-) -- 2.45.2

2 21

[PATCH] virnetdevopenvswitch: Warn on unsupported QoS settings
by Michal Privoznik 07 Nov '24

07 Nov '24

Let me preface this with stating the obvious: documentation on QoS in OVS is very sparse. This is all based on my observation and OVS codebase analysis. For the following QoS setting: <bandwidth> <inbound average="512" peak="1024" burst="32"/> </bandwidth> the following QoS setting is generated into OVS (NB, our XML values are in KiB/s, OVS has them in bits/s): # ovs-vsctl list qos _uuid : a087226b-2da6-4575-ad4c-bf570cb812a9 external_ids : {ifname=vnet1, vm-id="7714e6b5-4885-4140-bc59-2f77cc99b3b5"} other_config : {burst="262144", max-rate="8192000", min-rate="4096000"} queues : {0=655bf3a7-e530-4516-9caf-ec9555dfbd4c} type : linux-htb from which the following topology is generated: # for i in qdisc class; do tc -s -d -g $i show dev vnet1; done qdisc htb 1: root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 ver 3.17 direct_qlen 1000 Sent 2186 bytes 16 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 +---(1:fffe) htb rate 8192Kbit ceil 8192Kbit linklayer ethernet burst 1499b/1mpu 60b cburst 1499b/1mpu 60b level 7 | Sent 2186 bytes 16 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | +---(1:1) htb prio 0 quantum 51200 rate 4096Kbit ceil 8192Kbit linklayer ethernet burst 32Kb/1mpu 60b cburst 32Kb/1mpu 60b level 0 Sent 2186 bytes 16 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Long story short, the default class (1:) for an OVS interface has average and peak set exactly as requested. But since it's nested under another class (1:fffe), it can borrow unused bandwidth. And the parent is set to have rate = ceil = peak from our XML. From [1]: htb_tc_install() calls htb_parse_qdisc_details__() which sets: 'hc->min_rate = hc->max_rate;' and then calls htb_setup_class_(..., tc_make_handle(1, 0xfffe), tc_make_handle(1, 0), &hc); to set up the top parent class. In other words - the interface is set up to so that it can always consume 'peak' bandwidth and there is no way for us to set it up differently. It's too late to deny setting 'peak' different to 'average' at XML validation phase so do the next best thing - throw a warning, just like we do in case <bandwidth/> is set for an unsupported <interface/> type. 1: https://github.com/openvswitch/ovs/blob/main/lib/netdev-linux.c#L5039 Resolves: https://issues.redhat.com/browse/RHEL-53963 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnetdevopenvswitch.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c index e23f4c83b6..598cfa0031 100644 --- a/src/util/virnetdevopenvswitch.c +++ b/src/util/virnetdevopenvswitch.c @@ -945,6 +945,10 @@ virNetDevOpenvswitchInterfaceSetQos(const char *ifname, } if (tx && tx->average) { + if (tx->peak && tx->peak != tx->average) { + VIR_WARN("Setting different 'peak' value than 'average' for QoS for OVS interface %s is unsupported", + ifname); + } if (virNetDevOpenvswitchInterfaceSetTxQos(ifname, tx, vmuuid) < 0) return -1; } else { @@ -954,6 +958,10 @@ virNetDevOpenvswitchInterfaceSetQos(const char *ifname, } if (rx) { + if (rx->peak && tx->peak != rx->average) { + VIR_WARN("Setting different 'peak' value than 'average' for QoS for OVS interface %s is unsupported", + ifname); + } if (virNetDevOpenvswitchInterfaceSetRxQos(ifname, rx) < 0) return -1; } else { -- 2.45.2

2 1

[PATCH] docs: Soften language around use of virtio model name
by Andrea Bolognani 07 Nov '24

07 Nov '24

When virtio-(non-)transitional models were introduced, the documentation was updated to include them; at the same time, language was introduced indicating that using the existing virtio model is no longer recommended. This is unnecessarily harsh, and has resulted in people incorrectly believing (through no fault of their own) that the virtio model has been deprecated. In reality, it's perfectly fine to use the virtio model as the stress-free option that, while often not producing the ideal PCI topology, will generally get the job done and work reliably across libvirt versions and machine types. Tweak the documentation so that it hopefully carries the desired message across. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/formatdomain.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c50744b57b..b404ea8773 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3931,7 +3931,7 @@ machine types, accept the following ``model`` values: into a PCI Express slot, and like a ``virtio-transitional`` device otherwise; libvirt will pick one or the other based on the machine type. This is the best choice when compatibility with libvirt versions older than 5.2.0 is - necessary, but it's otherwise not recommended to use it. + necessary or if you're unsure which of the other two options to pick. While the information outlined above applies to most virtio devices, there are a few exceptions: -- 2.47.0

2 2

[PATCH v3 0/7] introduce job-change qmp command
by Vladimir Sementsov-Ogievskiy 07 Nov '24

07 Nov '24

Hi all! Here is new job-change command - a replacement for (becoming deprecated) block-job-change, as a first step of my "[RFC 00/15] block job API" v3: 01: add a-b by Markus 03: add a-b by Markus, s/9.1/9.2/ in QAPI 05: update commit message, s/9.1/9.2/ in QAPI 06: update commit message (and subject!), s/9.1/9.2/ in deprecated.rst Vladimir Sementsov-Ogievskiy (7): qapi: rename BlockJobChangeOptions to JobChangeOptions blockjob: block_job_change_locked(): check job type qapi: block-job-change: make copy-mode parameter optional blockjob: move change action implementation to job from block-job qapi: add job-change qapi/block-core: deprecate block-job-change iotests/mirror-change-copy-mode: switch to job-change command block/mirror.c | 13 +++++--- blockdev.c | 4 +-- blockjob.c | 20 ------------ docs/about/deprecated.rst | 5 +++ include/block/blockjob.h | 11 ------- include/block/blockjob_int.h | 7 ----- include/qemu/job.h | 12 +++++++ job-qmp.c | 15 +++++++++ job.c | 23 ++++++++++++++ qapi/block-core.json | 31 ++++++++++++++----- .../tests/mirror-change-copy-mode | 2 +- 11 files changed, 90 insertions(+), 53 deletions(-) -- 2.34.1

3 12

[PATCH 0/3] qemu_domain: Automagically add IOMMU if needed
by Michal Privoznik 07 Nov '24

07 Nov '24

*** BLURB HERE *** Michal Prívozník (3): libvirt_private.syms: Export virDomainIOMMUDefNew() qemu: Turn EIM IOMMU on automagically qemu_domain: Automagically add IOMMU if needed src/libvirt_private.syms | 1 + src/qemu/qemu_domain.c | 56 ++++++++++++++++++- src/qemu/qemu_validate.c | 1 - src/qemu/qemu_validate.h | 2 + ...-eim-autoadd.x86_64-latest.abi-update.args | 34 +++++++++++ ...u-eim-autoadd.x86_64-latest.abi-update.xml | 37 ++++++++++++ .../intel-iommu-eim-autoadd.xml | 34 +++++++++++ tests/qemuxmlconftest.c | 1 + 8 files changed, 164 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxmlconfdata/intel-iommu-eim-autoadd.x86_64-latest.abi-update.args create mode 100644 tests/qemuxmlconfdata/intel-iommu-eim-autoadd.x86_64-latest.abi-update.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-eim-autoadd.xml -- 2.45.2

2 4

[libvirt PATCH 0/3] coverity fixes
by Ján Tomko 06 Nov '24

06 Nov '24

Ján Tomko (3): qemu: chardev: avoid impossible overflow util: json: check return value of virJSONValueFromJsonC ch: check return value of virJSONValueArrayAppend src/ch/ch_monitor.c | 3 ++- src/qemu/qemu_chardev.c | 2 +- src/util/virjson.c | 5 +++++ 3 files changed, 8 insertions(+), 2 deletions(-) -- 2.47.0

2 4