January 2025 - Devel - libvirt List Archives

[PATCH 0/3] hw/sd/sdcard: Deprecate support for spec v1.10
by Philippe Mathieu-Daudé 01 Sep '25

01 Sep '25

Deprecate SD spec v1.10, use v3.01 as new default. Philippe Mathieu-Daudé (3): hw/sd/sdcard: Deprecate support for spec v1.10 hw/sd/sdcard: Use spec v3.01 by default hw/sd/sdcard: Remove support for spec v1.10 docs/about/removed-features.rst | 5 +++++ include/hw/sd/sd.h | 1 - hw/sd/sd.c | 14 +++----------- 3 files changed, 8 insertions(+), 12 deletions(-) -- 2.41.0

2 8

[PATCH v2 00/11] Enabling logging for ch guests
by Praveen K Paladugu 18 Aug '25

18 Aug '25

LogContext management is now moved from Qemu driver to hypervisor. After migrating Qemu to use domain_logcontext, I extended ch driver to use also use domain_logcontext to capture early boot failures within domain specific log files. Changes in V2: * refactored the patches to ensure all of them build. * ch driver will use virtlogd to consolidate logs from hypervisor and its domains. Praveen K Paladugu (11): hypervisor: copy qemu log context mgmt to hypervisor hypervisor: rename reference to qemu in domain_logcontext hypervisor: drop qemu specific args in domainLogContextNew hypervisor: Build domain_logcontext libvirt_private: export symbols from domain_logcontext qemu: Modify qemu driver to use domainLogContext qemu: delete qemu_logcontext files ch: Enable logging for ch domains ch: move curl_data and curl_callback definitions ch: Enable logging curl responses from ch ch: configure ch driver to use virlogd po/POTFILES | 2 +- src/ch/ch_conf.c | 1 + src/ch/ch_conf.h | 2 + src/ch/ch_monitor.c | 84 ++++++++++++------- src/ch/ch_monitor.h | 6 +- src/ch/ch_process.c | 36 ++++++-- .../domain_logcontext.c} | 78 +++++++++-------- src/hypervisor/domain_logcontext.h | 45 ++++++++++ src/hypervisor/meson.build | 1 + src/libvirt_private.syms | 6 ++ src/qemu/meson.build | 1 - src/qemu/qemu_domain.c | 28 +++---- src/qemu/qemu_domain.h | 12 +-- src/qemu/qemu_logcontext.h | 41 --------- src/qemu/qemu_nbdkit.c | 12 ++- src/qemu/qemu_process.c | 45 +++++----- 16 files changed, 236 insertions(+), 164 deletions(-) rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%) create mode 100644 src/hypervisor/domain_logcontext.h delete mode 100644 src/qemu/qemu_logcontext.h -- 2.47.0

4 16

[PATCH v1] tests: add capabilities for QEMU 10.0.0 on s390x
by Shalini Chellathurai Saroja 30 Apr '25

30 Apr '25

Let us introduce the xml and reply files for QEMU 10.0.0 on s390x. Notable changes: - new s390-ccw-virtio-10.0 machine type - old machine types (2.4 - 2.8) dropped - new CPU models - New devices: - virtio-mem-ccw - chardev now supports qemu-vdagent Signed-off-by: Shalini Chellathurai Saroja <shalini(a)linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Suggested-by: Michal Privoznik <mprivozn(a)redhat.com> The replies and xml files are removed from this patch and are available in https://gitlab.com/shalinichellathurai/libvirt/-/commit/3e9df63925e2c86b81c… --- tests/domaincapsdata/qemu_10.0.0.s390x.xml | 359 + .../caps_10.0.0_s390x.replies | 38002 ++++++++++++++++ .../caps_10.0.0_s390x.xml | 4216 ++ 3 files changed, 42577 insertions(+) create mode 100644 tests/domaincapsdata/qemu_10.0.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml diff --git a/tests/domaincapsdata/qemu_10.0.0.s390x.xml b/tests/domaincapsdata/qemu_10.0.0.s390x.xml new file mode 100644 index 0000000000..4af3c7ec53 --- /dev/null +++ b/tests/domaincapsdata/qemu_10.0.0.s390x.xml @@ -0,0 +1,359 @@ +<domainCapabilities> + <path>/usr/bin/qemu-system-s390x</path> + <domain>kvm</domain> + <machine>s390-ccw-virtio-10.0</machine> + <arch>s390x</arch> + <vcpu max='248'/> + <iothreads supported='yes'/> + <os supported='yes'> + <enum name='firmware'/> + <loader supported='yes'> + <value>/obviously/fake/firmware1.fd</value> + <value>/obviously/fake/firmware2.fd</value> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + <enum name='secure'> + <value>no</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='yes'> + <enum name='hostPassthroughMigratable'> + <value>off</value> + </enum> + </mode> + <mode name='maximum' supported='yes'> + <enum name='maximumMigratable'> + <value>on</value> + <value>off</value> + </enum> + </mode> + <mode name='host-model' supported='yes'> + <model fallback='forbid'>gen16a-base</model> + <feature policy='require' name='nnpa'/> + <feature policy='require' name='aen'/> + <feature policy='require' name='cmmnt'/> + <feature policy='require' name='vxpdeh'/> + <feature policy='require' name='aefsi'/> + <feature policy='require' name='diag318'/> + <feature policy='require' name='csske'/> + <feature policy='require' name='mepoch'/> + <feature policy='require' name='msa9'/> + <feature policy='require' name='msa8'/> + <feature policy='require' name='msa7'/> + <feature policy='require' name='msa6'/> + <feature policy='require' name='msa5'/> + <feature policy='require' name='msa4'/> + <feature policy='require' name='msa3'/> + <feature policy='require' name='msa2'/> + <feature policy='require' name='msa1'/> + <feature policy='require' name='sthyi'/> + <feature policy='require' name='edat'/> + <feature policy='require' name='ri'/> + <feature policy='require' name='deflate'/> + <feature policy='require' name='edat2'/> + <feature policy='require' name='etoken'/> + <feature policy='require' name='vx'/> + <feature policy='require' name='ipter'/> + <feature policy='require' name='pai'/> + <feature policy='require' name='paie'/> + <feature policy='require' name='mepochptff'/> + <feature policy='require' name='ap'/> + <feature policy='require' name='vxeh'/> + <feature policy='require' name='vxpd'/> + <feature policy='require' name='esop'/> + <feature policy='require' name='msa9_pckmo'/> + <feature policy='require' name='vxeh2'/> + <feature policy='require' name='esort'/> + <feature policy='require' name='appv'/> + <feature policy='require' name='apqi'/> + <feature policy='require' name='apft'/> + <feature policy='require' name='els'/> + <feature policy='require' name='iep'/> + <feature policy='require' name='appvi'/> + <feature policy='require' name='apqci'/> + <feature policy='require' name='cte'/> + <feature policy='require' name='ais'/> + <feature policy='require' name='bpb'/> + <feature policy='require' name='ctop'/> + <feature policy='require' name='gs'/> + <feature policy='require' name='ppa15'/> + <feature policy='require' name='zpci'/> + <feature policy='require' name='rdp'/> + <feature policy='require' name='sea_esop2'/> + <feature policy='require' name='beareh'/> + <feature policy='require' name='te'/> + <feature policy='require' name='cmm'/> + <feature policy='require' name='vxpdeh2'/> + </mode> + <mode name='custom' supported='yes'> + <model usable='yes' vendor='IBM'>gen15a</model> + <model usable='yes' vendor='IBM'>gen15a-base</model> + <model usable='yes' vendor='IBM'>gen15b</model> + <model usable='yes' vendor='IBM'>gen15b-base</model> + <model usable='yes' vendor='IBM'>gen16a</model> + <model usable='yes' vendor='IBM'>gen16a-base</model> + <model usable='yes' vendor='IBM'>gen16b</model> + <model usable='yes' vendor='IBM'>gen16b-base</model> + <model usable='no' vendor='IBM'>gen17a</model> + <blockers model='gen17a'> + <feature name='minste4'/> + <feature name='msa10'/> + <feature name='msa10_pckmo'/> + <feature name='msa11'/> + <feature name='msa11_pckmo'/> + <feature name='msa12'/> + <feature name='msa13'/> + <feature name='msa13_pckmo'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + <feature name='vxeh3'/> + <feature name='vxpdeh3'/> + </blockers> + <model usable='no' vendor='IBM'>gen17a-base</model> + <blockers model='gen17a-base'> + <feature name='minste4'/> + <feature name='msa12'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + </blockers> + <model usable='no' vendor='IBM'>gen17b</model> + <blockers model='gen17b'> + <feature name='minste4'/> + <feature name='msa10'/> + <feature name='msa10_pckmo'/> + <feature name='msa11'/> + <feature name='msa11_pckmo'/> + <feature name='msa12'/> + <feature name='msa13'/> + <feature name='msa13_pckmo'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + <feature name='vxeh3'/> + <feature name='vxpdeh3'/> + </blockers> + <model usable='no' vendor='IBM'>gen17b-base</model> + <blockers model='gen17b-base'> + <feature name='minste4'/> + <feature name='msa12'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + </blockers> + <model usable='yes' vendor='unknown'>max</model> + <model usable='yes' vendor='unknown'>qemu</model> + <model usable='yes' vendor='IBM'>z10BC</model> + <model usable='yes' vendor='IBM'>z10BC-base</model> + <model usable='yes' vendor='IBM'>z10BC.2</model> + <model usable='yes' vendor='IBM'>z10BC.2-base</model> + <model usable='yes' vendor='IBM'>z10EC</model> + <model usable='yes' vendor='IBM'>z10EC-base</model> + <model usable='yes' vendor='IBM'>z10EC.2</model> + <model usable='yes' vendor='IBM'>z10EC.2-base</model> + <model usable='yes' vendor='IBM'>z10EC.3</model> + <model usable='yes' vendor='IBM'>z10EC.3-base</model> + <model usable='yes' vendor='IBM'>z114</model> + <model usable='yes' vendor='IBM'>z114-base</model> + <model usable='yes' vendor='IBM'>z13</model> + <model usable='yes' vendor='IBM'>z13-base</model> + <model usable='yes' vendor='IBM'>z13.2</model> + <model usable='yes' vendor='IBM'>z13.2-base</model> + <model usable='yes' vendor='IBM'>z13s</model> + <model usable='yes' vendor='IBM'>z13s-base</model> + <model usable='yes' vendor='IBM'>z14</model> + <model usable='yes' vendor='IBM'>z14-base</model> + <model usable='yes' vendor='IBM'>z14.2</model> + <model usable='yes' vendor='IBM'>z14.2-base</model> + <model usable='yes' vendor='IBM'>z14ZR1</model> + <model usable='yes' vendor='IBM'>z14ZR1-base</model> + <model usable='yes' vendor='IBM'>z196</model> + <model usable='yes' vendor='IBM'>z196-base</model> + <model usable='yes' vendor='IBM'>z196.2</model> + <model usable='yes' vendor='IBM'>z196.2-base</model> + <model usable='yes' vendor='IBM'>z800</model> + <model usable='yes' vendor='IBM'>z800-base</model> + <model usable='yes' vendor='IBM'>z890</model> + <model usable='yes' vendor='IBM'>z890-base</model> + <model usable='yes' vendor='IBM'>z890.2</model> + <model usable='yes' vendor='IBM'>z890.2-base</model> + <model usable='yes' vendor='IBM'>z890.3</model> + <model usable='yes' vendor='IBM'>z890.3-base</model> + <model usable='yes' vendor='IBM'>z900</model> + <model usable='yes' vendor='IBM'>z900-base</model> + <model usable='yes' vendor='IBM'>z900.2</model> + <model usable='yes' vendor='IBM'>z900.2-base</model> + <model usable='yes' vendor='IBM'>z900.3</model> + <model usable='yes' vendor='IBM'>z900.3-base</model> + <model usable='yes' vendor='IBM'>z990</model> + <model usable='yes' vendor='IBM'>z990-base</model> + <model usable='yes' vendor='IBM'>z990.2</model> + <model usable='yes' vendor='IBM'>z990.2-base</model> + <model usable='yes' vendor='IBM'>z990.3</model> + <model usable='yes' vendor='IBM'>z990.3-base</model> + <model usable='yes' vendor='IBM'>z990.4</model> + <model usable='yes' vendor='IBM'>z990.4-base</model> + <model usable='yes' vendor='IBM'>z990.5</model> + <model usable='yes' vendor='IBM'>z990.5-base</model> + <model usable='yes' vendor='IBM'>z9BC</model> + <model usable='yes' vendor='IBM'>z9BC-base</model> + <model usable='yes' vendor='IBM'>z9BC.2</model> + <model usable='yes' vendor='IBM'>z9BC.2-base</model> + <model usable='yes' vendor='IBM'>z9EC</model> + <model usable='yes' vendor='IBM'>z9EC-base</model> + <model usable='yes' vendor='IBM'>z9EC.2</model> + <model usable='yes' vendor='IBM'>z9EC.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.3</model> + <model usable='yes' vendor='IBM'>z9EC.3-base</model> + <model usable='yes' vendor='IBM'>zBC12</model> + <model usable='yes' vendor='IBM'>zBC12-base</model> + <model usable='yes' vendor='IBM'>zEC12</model> + <model usable='yes' vendor='IBM'>zEC12-base</model> + <model usable='yes' vendor='IBM'>zEC12.2</model> + <model usable='yes' vendor='IBM'>zEC12.2-base</model> + </mode> + </cpu> + <memoryBacking supported='yes'> + <enum name='sourceType'> + <value>file</value> + <value>anonymous</value> + <value>memfd</value> + </enum> + </memoryBacking> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + <value>floppy</value> + <value>lun</value> + </enum> + <enum name='bus'> + <value>fdc</value> + <value>scsi</value> + <value>virtio</value> + <value>usb</value> + </enum> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + </disk> + <graphics supported='yes'> + <enum name='type'> + <value>sdl</value> + <value>vnc</value> + <value>egl-headless</value> + <value>dbus</value> + </enum> + </graphics> + <video supported='yes'> + <enum name='modelType'> + <value>virtio</value> + <value>none</value> + </enum> + </video> + <hostdev supported='yes'> + <enum name='mode'> + <value>subsystem</value> + </enum> + <enum name='startupPolicy'> + <value>default</value> + <value>mandatory</value> + <value>requisite</value> + <value>optional</value> + </enum> + <enum name='subsysType'> + <value>usb</value> + <value>pci</value> + <value>scsi</value> + </enum> + <enum name='capsType'/> + <enum name='pciBackend'> + <value>default</value> + <value>vfio</value> + </enum> + </hostdev> + <rng supported='yes'> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + <enum name='backendModel'> + <value>random</value> + <value>egd</value> + <value>builtin</value> + </enum> + </rng> + <filesystem supported='yes'> + <enum name='driverType'> + <value>path</value> + <value>handle</value> + <value>virtiofs</value> + </enum> + </filesystem> + <tpm supported='no'/> + <redirdev supported='yes'> + <enum name='bus'> + <value>usb</value> + </enum> + </redirdev> + <channel supported='yes'> + <enum name='type'> + <value>pty</value> + <value>unix</value> + </enum> + </channel> + <crypto supported='yes'> + <enum name='model'> + <value>virtio</value> + </enum> + <enum name='type'> + <value>qemu</value> + </enum> + <enum name='backendModel'> + <value>builtin</value> + <value>lkcf</value> + </enum> + </crypto> + <interface supported='yes'> + <enum name='backendType'> + <value>default</value> + <value>passt</value> + </enum> + </interface> + <panic supported='yes'> + <enum name='model'> + <value>s390</value> + </enum> + </panic> + </devices> + <features> + <gic supported='no'/> + <vmcoreinfo supported='no'/> + <genid supported='no'/> + <backingStoreInput supported='yes'/> + <backup supported='yes'/> + <async-teardown supported='yes'/> + <s390-pv supported='yes'/> + <ps2 supported='no'/> + <sev supported='no'/> + <sgx supported='no'/> + <launchSecurity supported='yes'> + <enum name='sectype'> + <value>s390-pv</value> + </enum> + </launchSecurity> + </features> +</domainCapabilities> diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies new file mode 100644 index 0000000000..5195489878 --- /dev/null +++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies @@ -0,0 +1,38002 @@ [...] diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml new file mode 100644 index 0000000000..242848d6ae --- /dev/null +++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml @@ -0,0 +1,4216 @@ [...]

3 3

[PATCH rfcv4 00/13] LIBVIRT: X86: TDX support
by Zhenzhong Duan 02 Apr '25

02 Apr '25

Hi, This series brings libvirt the x86 TDX support. * What's TDX? TDX stands for Trust Domain Extensions which isolates VMs from the virtual-machine manager (VMM)/hypervisor and any other software on the platform. To support TDX, multiple software components, not only KVM but also QEMU, guest Linux and virtual bios, need to be updated. For more details, please check link[1]. This patchset is another software component to extend libvirt to support TDX, with which one can start a TDX guest from high level rather than running qemu directly. * Misc As QEMU use a software emulated way to reset guest which isn't supported by TDX guest for security reason. We simulate reboot for TDX guest by kill and create a new one in FakeReboot framework. Complete code can be found at [2], matching qemu code can be found at [3]. There is a 'debug' property for tdx-guest object which isn't in matching qemu[3] yet. I keep them intentionally as they will be implemented in qemu as extention series of [3]. * Test start/stop/reboot with virsh stop/reboot trigger in guest stop with on_poweroff=destroy/restart reboot with on_reboot=destroy/restart * Patch organization - patch 1-4: Support query of TDX capabilities. - patch 5-8: Add TDX type to launchsecurity framework. - patch 9-11: Add reboot support to TDX guest - patch 12-13: Add test and docs TODO: - update QEMU capabilities data in tests, depending on qemu TDX merged beforehand - add reconnect logic in virsh command [1] https://lore.kernel.org/kvm/cover.1708933498.git.isaku.yamahata@intel.com [2] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_rfcv4 [3] https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream-v5 Thanks Zhenzhong Changelog: rfcv4: - add a check to tools/virt-host-validate-qemu.c (Daniel) - remove check of q35 (Daniel) - model 'SocktetAddress' QAPI in xml schema (Daniel) - s/Quote-Generation-Service/quoteGenerationService/ (Daniel) - define bits in tdx->policy and add validating logic (Daniel) - presume QEMU choose split kernel irqchip for TDX guest by default (Daniel) - utilize existing FakeReboot framework to do reboot for TDX guest (Daniel) - drop patch11 'conf: Add support to keep same domid for hard reboot' (Daniel) - add test in tests/ to validate parsing and formatting logic (Daniel) - add doc in docs/formatdomain.rst (Daniel) - add R-B rfcv3: - Change to generate qemu cmdline with -bios - drop firmware auto match as -bios is used - add a hard reboot method to reboot TDX guest rfcv3: https://www.mail-archive.com/devel@lists.libvirt.org/msg00385.html rfcv2: - give up using qmp cmd and check TDX directly on host for TDX capabilities. - use launchsecurity framework to support TDX - use <os>.<loader> for general loader - add auto firmware match feature for TDX A example TDVF fimware description file 70-edk2-x86_64-tdx.json: { "description": "UEFI firmware for x86_64, supporting Intel TDX", "interface-types": [ "uefi" ], "mapping": { "device": "generic", "filename": "/usr/share/OVMF/OVMF_CODE-tdx.fd" }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "intel-tdx", "verbose-dynamic" ], "tags": [ ] } rfcv2: https://www.mail-archive.com/libvir-list@redhat.com/msg219378.html Zhenzhong Duan (13): tools: Secure guest check for Intel in virt-host-validate qemu: Check if INTEL Trust Domain Extention support is enabled qemu: Add TDX capability conf: expose TDX feature in domain capabilities conf: add tdx as launch security type qemu: Add command line and validation for TDX type qemu: force special parameters enabled for TDX guest Add Intel TDX Quote Generation Service(QGS) support qemu: add FakeReboot support for TDX guest qemu: Support reboot command in guest qemu: Avoid duplicate FakeReboot for secure guest Add test cases for Intel TDX docs: domain: Add documentation for Intel TDX guest docs/formatdomain.rst | 68 ++++ docs/formatdomaincaps.rst | 1 + src/conf/domain_capabilities.c | 1 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 312 ++++++++++++++++++ src/conf/domain_conf.h | 75 +++++ src/conf/schemas/domaincaps.rng | 9 + src/conf/schemas/domaincommon.rng | 135 ++++++++ src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 36 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 139 ++++++++ src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 28 +- src/qemu/qemu_monitor.h | 2 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_namespace.c | 1 + src/qemu/qemu_process.c | 75 +++++ src/qemu/qemu_validate.c | 44 +++ ...unch-security-tdx-qgs-fd.x86_64-latest.xml | 77 +++++ .../launch-security-tdx-qgs-fd.xml | 30 ++ ...ch-security-tdx-qgs-inet.x86_64-latest.xml | 77 +++++ .../launch-security-tdx-qgs-inet.xml | 30 ++ ...ch-security-tdx-qgs-unix.x86_64-latest.xml | 77 +++++ .../launch-security-tdx-qgs-unix.xml | 30 ++ ...h-security-tdx-qgs-vsock.x86_64-latest.xml | 77 +++++ .../launch-security-tdx-qgs-vsock.xml | 30 ++ tests/qemuxmlconftest.c | 24 ++ tools/virt-host-validate-common.c | 22 +- tools/virt-host-validate-common.h | 1 + 30 files changed, 1407 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-fd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-fd.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-inet.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-inet.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-unix.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-unix.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-vsock.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx-qgs-vsock.xml -- 2.34.1

6 45

[PATCH 00/26] integrate auto-shutdown of VMs with daemons
by Daniel P. Berrangé 11 Mar '25

11 Mar '25

This series starts the work needed to obsolete the libvirt-guests.sh script which has grown a surprisingly large amount of functionality. Currently the virt daemons will acquire inhibitors to delay OS shutdown when VMs are running. The libvirt-guests.service unit can be used to call libvirt-guests.sh to shutdown running VMs on system shutdown. This split is a bad architecture because libvirt-guests.service will only run once the system has decided to initiate the shutdown sequence. When the user requests as shutdown while inhibitors are present, logind will emit a "PrepareForShutdown" signal over dbus. Applications are supposed to respond to this by preserving state & releasing their inhibitors, which in turns allows shutdown to be initiated. The remote daemon already has support for listening for the "PrepareForShutdown" signal, but only does this for session instances, not system instances. This series essentially takes that logic and expands it to run in the system instances too, thus conceptually making libvirt-guests.service obsolete. It is slightly more complicated than that though for many reasons... Saving running VMs can take a very long time. The inhibitor delay can be as low as 5 seconds, and when killing a service, systemd may not wait very long for it to terminate. libvirt-guests.service deals with this by setting TimeoutStopSecs=0 to make systemd wait forever. This is undesirable to set in libvirtd.service though, as we would like systemd to kill the daemon aggressively if it hangs. The series thus uses the notification protocol to request systemd give it more time to shutdown, as long as we're in the phase of saving running VMs. A bug in this code will still result in systemd waiting forever, which is no different from libvirt-guests.service, but a bug in any other part of the libvirt daemon shutdown code will result in systemd killing us. The existing logic for saving VMs in the session daemons had many feature gaps compared to libvirt-guests.sh. Thus there is code to add support * Requesting graceful OS shutdown if managed save failed * Force poweroff of VMs if no other action worked * Optionally enabling/disabling use of managed save, graceful shutdown and force poweroff, which is more flexible than ON_SHUTDOWN=nnn, as we can try the whole sequence of options * Ability to bypass cache in managed save * Support for one-time autostart of VMs as an official API To aid in testing this logic, virt-admin gains a new command 'virt-admin daemon-shutdown --preserve' All this new functionality is wired up into the QEMU driver, and is made easily accessible to other hypervisor drivers, so would easily be extendable to Xen, CH, LXC drivers, but this is not done in this series. IOW, libvirt-guests.service is not yet fully obsolete. The new functionality is also not enabled by default for the system daemon, it requires explicit admin changes to /etc/libvirt/qemu.conf to enable it. This is because it would clash with execution of the libvirt-guests.service if both were enabled. It is highly desirable that we enable this by default though, so we need to figure out a upgrade story wrt libvirt-guests.service. The only libvirt-guests.sh features not implemented are: * PARALLEL_SHUTDOWN=nn. When doing a graceful shutdown we initiate it on every single VM at once, and then monitor progress of all of them in parallel. * SYNC_TIME=nn When make not attempt to sync guest time when restoring from managed save. This ought to be fixed Daniel P. Berrangé (26): util: add APIs for more systemd notifications remote: notify systemd when reloading config hypervisor: introduce helper for autostart src: convert drivers over to use new autostart helper hypervisor: add support for delay interval during autostart qemu: add 'auto_start_delay' configuration parameter hypervisor: move support for auto-shutdown out of QEMU driver remote: always invoke virStateStop for all daemons hypervisor: expand available shutdown actions hypervisor: custom shutdown actions for transient vs persistent VMs qemu: support automatic VM managed save in system daemon qemu: improve shutdown defaults for session daemon qemu: configurable delay for shutdown before poweroff hypervisor: support bypassing cache for managed save qemu: add config parameter to control auto-save bypass cache src: add new APIs for marking a domain to autostart once conf: implement support for autostart once feature hypervisor: wire up support for auto restore of running domains qemu: wire up support for once only autostart qemu: add config to control if auto-shutdown VMs are restored rpc: move state stop into virNetDaemon class rpc: don't unconditionally quit after preserving state rpc: fix shutdown sequence when preserving state admin: add 'daemon-shutdown' command rpc: don't let systemd shutdown daemon while saving VMs hypervisor: send systemd status messages while saving include/libvirt/libvirt-admin.h | 13 ++ include/libvirt/libvirt-domain.h | 4 + src/admin/admin_protocol.x | 11 +- src/admin/admin_server_dispatch.c | 13 ++ src/admin/libvirt-admin.c | 33 ++++ src/admin/libvirt_admin_public.syms | 5 + src/bhyve/bhyve_driver.c | 53 ++---- src/conf/domain_conf.c | 6 +- src/conf/domain_conf.h | 1 + src/conf/virdomainobjlist.c | 7 +- src/driver-hypervisor.h | 10 ++ src/hypervisor/domain_driver.c | 250 ++++++++++++++++++++++++++++ src/hypervisor/domain_driver.h | 42 +++++ src/libvirt-domain.c | 87 ++++++++++ src/libvirt_private.syms | 10 +- src/libvirt_public.syms | 6 + src/libvirt_remote.syms | 2 +- src/libxl/libxl_driver.c | 36 ++-- src/lxc/lxc_driver.c | 13 +- src/lxc/lxc_process.c | 18 +- src/lxc/lxc_process.h | 2 + src/qemu/libvirtd_qemu.aug | 7 + src/qemu/qemu.conf.in | 59 +++++++ src/qemu/qemu_conf.c | 63 +++++++ src/qemu/qemu_conf.h | 7 + src/qemu/qemu_driver.c | 203 +++++++++++++--------- src/qemu/test_libvirtd_qemu.aug.in | 7 + src/remote/libvirtd.service.in | 2 +- src/remote/remote_daemon.c | 78 +++------ src/remote/remote_driver.c | 2 + src/remote/remote_protocol.x | 30 +++- src/remote_protocol-structs | 12 ++ src/rpc/gendispatch.pl | 4 +- src/rpc/virnetdaemon.c | 212 +++++++++++++++++++---- src/rpc/virnetdaemon.h | 20 ++- src/util/virsystemd.c | 41 ++++- src/util/virsystemd.h | 6 +- src/virtd.service.in | 2 +- tools/virsh-domain-monitor.c | 5 + tools/virsh-domain.c | 39 ++++- tools/virt-admin.c | 41 +++++ 41 files changed, 1181 insertions(+), 281 deletions(-) -- 2.47.1

2 73

[PATCH 0/3] Full boot order support on s390x
by Boris Fiuczynski 11 Mar '25

11 Mar '25

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 11

[PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
by Philippe Mathieu-Daudé 10 Mar '25

10 Mar '25

We are trying to unify all qemu-system-FOO to a single binary. In order to do that we need to remove QAPI target specific code. @dump-skeys is only available on qemu-system-s390x. This series rename it as @dump-s390-skey, making it available on other binaries. We take care of backward compatibility via deprecation. Philippe Mathieu-Daudé (4): hw/s390x: Introduce the @dump-s390-skeys QMP command hw/s390x: Introduce the 'dump_s390_skeys' HMP command hw/s390x: Deprecate the HMP 'dump_skeys' command hw/s390x: Deprecate the QMP @dump-skeys command docs/about/deprecated.rst | 5 +++++ qapi/misc-target.json | 5 +++++ qapi/misc.json | 18 ++++++++++++++++++ include/monitor/hmp.h | 1 + hw/s390x/s390-skeys-stub.c | 24 ++++++++++++++++++++++++ hw/s390x/s390-skeys.c | 19 +++++++++++++++++-- hmp-commands.hx | 17 +++++++++++++++-- hw/s390x/meson.build | 5 +++++ 8 files changed, 90 insertions(+), 4 deletions(-) create mode 100644 hw/s390x/s390-skeys-stub.c -- 2.41.0

7 24

[PATCH] util: netdevvlan: Change return type of virNetDevVlanCopy to void
by Alexander Kuznetsov 07 Mar '25

07 Mar '25

This function return value is invariant since 1022e0ee, so change its type and remove all dependent checks. Found by Linux Verification Center (linuxtesting.org) with Svace. Reported-by: Alexander Rudyuk <a.rudyuk(a)fobos-nt.ru> Signed-off-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org> --- src/conf/domain_conf.c | 9 +++------ src/network/bridge_driver.c | 4 +++- src/util/virnetdevvlan.c | 6 +++--- src/util/virnetdevvlan.h | 2 +- 4 files changed, 10 insertions(+), 11 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 3f88a77a8f..6f49ee507a 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30533,8 +30533,7 @@ virDomainNetDefToNetworkPort(virDomainDef *dom, if (virNetDevBandwidthCopy(&port->bandwidth, iface->bandwidth) < 0) return NULL; - if (virNetDevVlanCopy(&port->vlan, &iface->vlan) < 0) - return NULL; + virNetDevVlanCopy(&port->vlan, &iface->vlan); port->isolatedPort = iface->isolatedPort; port->trustGuestRxFilters = iface->trustGuestRxFilters; @@ -30611,8 +30610,7 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface, if (virNetDevBandwidthCopy(&actual->bandwidth, port->bandwidth) < 0) goto error; - if (virNetDevVlanCopy(&actual->vlan, &port->vlan) < 0) - goto error; + virNetDevVlanCopy(&actual->vlan, &port->vlan); actual->isolatedPort = port->isolatedPort; actual->class_id = port->class_id; @@ -30729,8 +30727,7 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom, if (virNetDevBandwidthCopy(&port->bandwidth, actual->bandwidth) < 0) return NULL; - if (virNetDevVlanCopy(&port->vlan, &actual->vlan) < 0) - return NULL; + virNetDevVlanCopy(&port->vlan, &actual->vlan); port->isolatedPort = actual->isolatedPort; port->class_id = actual->class_id; diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 8f47ef2574..668870a9ee 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -3973,8 +3973,10 @@ networkAllocatePort(virNetworkObj *obj, else if (netdef->vlan.nTags > 0) vlan = &netdef->vlan; - if (vlan && virNetDevVlanCopy(&port->vlan, vlan) < 0) + if (vlan) { + virNetDevVlanCopy(&port->vlan, vlan); return -1; + } } if (!port->trustGuestRxFilters) { diff --git a/src/util/virnetdevvlan.c b/src/util/virnetdevvlan.c index 67daa5d3b4..e8f572efd2 100644 --- a/src/util/virnetdevvlan.c +++ b/src/util/virnetdevvlan.c @@ -76,11 +76,11 @@ virNetDevVlanEqual(const virNetDevVlan *a, const virNetDevVlan *b) * If src is NULL, dst will have nTags set to 0. * dst is assumed to be empty on entry. */ -int +void virNetDevVlanCopy(virNetDevVlan *dst, const virNetDevVlan *src) { if (!src || src->nTags == 0) - return 0; + return; dst->tag = g_new0(unsigned int, src->nTags); dst->trunk = src->trunk; @@ -88,5 +88,5 @@ virNetDevVlanCopy(virNetDevVlan *dst, const virNetDevVlan *src) dst->nativeMode = src->nativeMode; dst->nativeTag = src->nativeTag; memcpy(dst->tag, src->tag, src->nTags * sizeof(*src->tag)); - return 0; + return; } diff --git a/src/util/virnetdevvlan.h b/src/util/virnetdevvlan.h index 228d270869..fd2f8023f5 100644 --- a/src/util/virnetdevvlan.h +++ b/src/util/virnetdevvlan.h @@ -42,6 +42,6 @@ struct _virNetDevVlan { void virNetDevVlanClear(virNetDevVlan *vlan); void virNetDevVlanFree(virNetDevVlan *vlan); int virNetDevVlanEqual(const virNetDevVlan *a, const virNetDevVlan *b); -int virNetDevVlanCopy(virNetDevVlan *dst, const virNetDevVlan *src); +void virNetDevVlanCopy(virNetDevVlan *dst, const virNetDevVlan *src); G_DEFINE_AUTOPTR_CLEANUP_FUNC(virNetDevVlan, virNetDevVlanFree); -- 2.42.4

2 5

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[PATCH] qemu: snapshot: Remove dead code in qemuSnapshotDeleteBlockJobFinishing()
by Alexander Kuznetsov 06 Mar '25

06 Mar '25

qemuSnapshotDeleteBlockJobFinishing() returns only 0 and 1. Convert it to bool and remove the dead code handling -1 return in the caller. Found by Linux Verification Center (linuxtesting.org) with Svace. Reported-by: Reported-by: Andrey Slepykh <a.slepykh(a)fobos-nt.ru> Signed-off-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org> --- src/qemu/qemu_snapshot.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 80cd54bf33..d277f76b4b 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -3465,7 +3465,7 @@ qemuSnapshotDeleteBlockJobIsRunning(qemuBlockjobState state) /* When finishing or aborting qemu blockjob we only need to know if the * job is still active or not. */ -static int +static bool qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) { switch (state) { @@ -3475,7 +3475,7 @@ qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) case QEMU_BLOCKJOB_STATE_ABORTING: case QEMU_BLOCKJOB_STATE_PENDING: case QEMU_BLOCKJOB_STATE_PIVOTING: - return 1; + return true; case QEMU_BLOCKJOB_STATE_COMPLETED: case QEMU_BLOCKJOB_STATE_FAILED: @@ -3485,7 +3485,7 @@ qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) break; } - return 0; + return false; } @@ -3513,18 +3513,14 @@ static int qemuSnapshotDeleteBlockJobFinishing(virDomainObj *vm, qemuBlockJobData *job) { - int rc; qemuBlockJobUpdate(vm, job, VIR_ASYNC_JOB_SNAPSHOT); - while ((rc = qemuSnapshotDeleteBlockJobIsActive(job->state)) > 0) { + while (qemuSnapshotDeleteBlockJobIsActive(job->state)) { if (qemuDomainObjWait(vm) < 0) return -1; qemuBlockJobUpdate(vm, job, VIR_ASYNC_JOB_SNAPSHOT); } - if (rc < 0) - return -1; - return 0; } -- 2.42.4

2 2