[PATCH 0/2] disk hotplug support for test hypervisor
by John Levon
John Levon (2):
test_driver: provide basic disk hotplug support
test_driver: provide basic disk hotunplug support
src/test/test_driver.c | 276 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 273 insertions(+), 3 deletions(-)
--
2.34.1
2 months
[PATCH 0/2] ch_monitor: Two simple improvements
by Michal Privoznik
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 months
[PATCH v3 00/17] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé
Missing review: 4 (new) & 10
Since v2:
- Addressed Richard's review comments
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é (17):
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
hw/arm/xlnx-zynqmp: Use &error_abort for programming errors
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 | 40 +++++--------
hw/char/xilinx_uartlite.c | 31 ++++++----
hw/intc/xilinx_intc.c | 50 ++++++++++++----
hw/microblaze/boot.c | 8 +--
hw/microblaze/petalogix_ml605_mmu.c | 4 +-
hw/microblaze/petalogix_s3adsp1800_mmu.c | 58 ++++++++++++++++---
hw/microblaze/xlnx-zynqmp-pmu.c | 2 +-
hw/net/xilinx_ethlite.c | 42 +++++++++-----
hw/ppc/virtex_ml507.c | 1 +
hw/ssi/xilinx_spi.c | 24 +++++---
hw/ssi/xilinx_spips.c | 36 +++++++-----
hw/timer/xilinx_timer.c | 33 +++++++----
target/microblaze/translate.c | 49 ++++++++++------
.../functional/test_microblaze_s3adsp1800.py | 27 ++++++++-
.../test_microblazeel_s3adsp1800.py | 25 +++++++-
19 files changed, 309 insertions(+), 134 deletions(-)
--
2.45.2
2 months
[PATCH v2 0/4] Full boot order support on s390x
by Boris Fiuczynski
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
2 months
[PATCH 00/13] qemu: NVRAM template handling fixes and support for block device backed NVRAM
by Peter Krempa
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
2 months
[PATCH 0/3] Do not try hot(un)plugging platform char devices
by Martin Kletzander
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 months
[PATCH v2 00/16] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé
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 months, 1 week
[PATCH] virnetdevopenvswitch: Warn on unsupported QoS settings
by Michal Privoznik
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 months, 1 week
[PATCH 0/3] Full boot order support on s390x
by Boris Fiuczynski
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/
The replies and xml files are removed from the patch in this series and
are available in https://gitlab.com/fiuczy/libvirt/-/commits/fullbootorder
Boris Fiuczynski (3):
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
src/qemu/qemu_capabilities.c | 8 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 40 +-
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 +
26 files changed, 42664 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
2 months, 1 week
[PATCH] docs: Soften language around use of virtio model name
by Andrea Bolognani
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 months, 1 week
