February 2024 - Devel - libvirt List Archives

[PATCH v4 00/12] nodedev state and update
by Boris Fiuczynski 21 Feb '24

21 Feb '24

The series adds a dual state to the mdev node devices as these objects can be active and defined at the same time. These two states can become different. To be able to also introspect the persistent and transient nodedevs filtering is added. To be able to also dump the XML of an inactive state while the node device is active a new option is added. The last four patches add the capability to update a mdev node device. This can be done on the persistent configuration, on the active configuration or on both. To support this v1.3.0 of mdevctl is required. nodeDeviceDefineXML() does now support modifying a persistent configuration. Changes since v3: * replaced in all patches occurrences of persisted with persistent Changes since v2: * made error messages in virNodeDeviceObjUpdateModificationImpact() device type agnostic * renamed virNodeDeviceUpdateXML* into virNodeDeviceUpdate* * renamed nodeDeviceDefCompareMdevs() into nodeDeviceDefValidateUpdate() * renamed multiple local variable names * removed method for config cloning by commenting cross config compare in nodeDeviceDefValidateUpdate() * changed nodeDeviceDefineXML() to modify an existing persistent configuration Changes since v1: * replaced spec file requirement for v1.3.0 of mdevctl by a dynamic support check and an unsupported message if not available * removed persisted precheck in virsh * renamed persisted and persist into persistent * addressed all other review comments made on v1 * added NEWS Boris Fiuczynski (12): virmdev: prepare type and attributes for dual state node_device: refactor mdev attributes handling node_device: remove unnecessary checks in virNodeDeviceDefFormat nodedev: add an active config to mdev tools: add option inactive to nodedev-dumpxml nodedev: add persistent and transient filter on list tools: add switches persistent and transient to nodedev-list virsh: doc fix on nodedev-list api: add virNodeDeviceUpdate() nodedev: Implement virNodeDeviceUpdate virsh: add nodedev-update nodedev: allow modify on define of a persistent node device NEWS.rst | 12 + docs/drvnodedev.rst | 4 +- docs/manpages/virsh.rst | 36 +- include/libvirt/libvirt-nodedev.h | 31 ++ libvirt.spec.in | 1 + src/access/viraccessperm.c | 1 + src/access/viraccessperm.h | 6 + src/conf/node_device_conf.c | 76 +-- src/conf/node_device_conf.h | 14 +- src/conf/virnodedeviceobj.c | 50 ++ src/conf/virnodedeviceobj.h | 3 + src/driver-nodedev.h | 6 + src/libvirt-nodedev.c | 51 +- src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 + src/node_device/node_device_driver.c | 489 ++++++++++++++---- src/node_device/node_device_driver.h | 17 +- src/node_device/node_device_udev.c | 5 +- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 +- src/remote_protocol-structs | 6 + src/test/test_driver.c | 6 +- src/util/virmdev.h | 6 + ...60c_c60c_c60c_c60c_c60cc60cc60c_update.xml | 16 + tests/nodedevmdevctldata/mdevctl-modify.argv | 25 + tests/nodedevmdevctldata/mdevctl-modify.json | 4 + tests/nodedevmdevctltest.c | 94 +++- ...v_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml | 14 + ...d_b7f0_4fea_b468_f1da537d301b_inactive.xml | 1 + ...v_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml | 10 + ...c_c60c_c60c_c60c_c60cc60cc60c_inactive.xml | 9 + ...9_36ea_4111_8f0a_8c9a70e21366_inactive.xml | 1 + ...9_495e_4243_ad9f_beb3f14c23d9_inactive.xml | 1 + ...4_f554_4dc1_809d_b2a01e8e48ad_inactive.xml | 8 + ...6_1ca8_49ac_b176_871d16c13076_inactive.xml | 1 + tests/nodedevxml2xmltest.c | 59 ++- tools/virsh-nodedev.c | 140 ++++- 37 files changed, 1067 insertions(+), 160 deletions(-) create mode 100644 tests/nodedevmdevctldata/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c_update.xml create mode 100644 tests/nodedevmdevctldata/mdevctl-modify.argv create mode 100644 tests/nodedevmdevctldata/mdevctl-modify.json create mode 100644 tests/nodedevschemadata/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml create mode 120000 tests/nodedevxml2xmlout/mdev_3627463d_b7f0_4fea_b468_f1da537d301b_inactive.xml create mode 100644 tests/nodedevxml2xmlout/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml create mode 100644 tests/nodedevxml2xmlout/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9_inactive.xml create mode 100644 tests/nodedevxml2xmlout/mdev_ee0b88c4_f554_4dc1_809d_b2a01e8e48ad_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_fedc4916_1ca8_49ac_b176_871d16c13076_inactive.xml -- 2.42.0

1 12

[PATCH v2 0/4] Rewrite x86 feature sync script
by Tim Wiederhake 20 Feb '24

20 Feb '24

Previously, sync_qemu_features_i386.py would only detect differences between libvirt's and qemu's list of x86 features. Adding those features to libvirt was a manual and error prone task. Additionally, we had to keep a list of non-feature cpu properties that qemu reported. Replace this script with a version that reads the feature names and their cpuid / msr data from qemu source code directly and generate the libvirt feature list, thus avoiding potential for human error. v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/OV5H… changes since v1: * rebased to current master (some conflicts in tests/ due to 8c07850c18) * dropped patch 4 ("cpu_map: Remove unused alias information") * adjusted patch 5 to generate "<alias .../>" entries Tim Wiederhake (4): cpu_map: Sort cpu features cpu_map: Format register values cpu_map: Format comments cpu_map: Rewrite feature sync script src/cpu_map/sync_qemu_features_i386.py | 627 ++++++++++---- src/cpu_map/x86_features.xml | 807 +++++++++--------- ...4-baseline-Westmere+Nehalem-migratable.xml | 4 +- ...86_64-baseline-Westmere+Nehalem-result.xml | 4 +- .../x86_64-baseline-features-result.xml | 4 +- .../x86_64-cpuid-A10-5800K-guest.xml | 8 +- .../x86_64-cpuid-A10-5800K-host.xml | 8 +- .../x86_64-cpuid-A10-5800K-json.xml | 8 +- .../x86_64-cpuid-Atom-D510-guest.xml | 16 +- .../x86_64-cpuid-Atom-D510-host.xml | 16 +- .../x86_64-cpuid-Atom-N450-guest.xml | 14 +- .../x86_64-cpuid-Atom-N450-host.xml | 14 +- .../x86_64-cpuid-Atom-P5362-guest.xml | 12 +- .../x86_64-cpuid-Atom-P5362-host.xml | 18 +- .../x86_64-cpuid-Atom-P5362-json.xml | 8 +- .../x86_64-cpuid-Cooperlake-guest.xml | 12 +- .../x86_64-cpuid-Cooperlake-host.xml | 12 +- .../x86_64-cpuid-Cooperlake-json.xml | 8 +- .../x86_64-cpuid-Core-i5-2500-guest.xml | 14 +- .../x86_64-cpuid-Core-i5-2500-host.xml | 14 +- .../x86_64-cpuid-Core-i5-2500-json.xml | 4 +- .../x86_64-cpuid-Core-i5-2540M-guest.xml | 14 +- .../x86_64-cpuid-Core-i5-2540M-host.xml | 14 +- .../x86_64-cpuid-Core-i5-2540M-json.xml | 4 +- .../x86_64-cpuid-Core-i5-4670T-guest.xml | 16 +- .../x86_64-cpuid-Core-i5-4670T-host.xml | 16 +- .../x86_64-cpuid-Core-i5-4670T-json.xml | 6 +- .../x86_64-cpuid-Core-i5-650-guest.xml | 14 +- .../x86_64-cpuid-Core-i5-650-host.xml | 14 +- .../x86_64-cpuid-Core-i5-650-json.xml | 4 +- .../x86_64-cpuid-Core-i5-6600-guest.xml | 12 +- .../x86_64-cpuid-Core-i5-6600-host.xml | 12 +- .../x86_64-cpuid-Core-i5-6600-json.xml | 2 +- .../x86_64-cpuid-Core-i7-2600-guest.xml | 14 +- .../x86_64-cpuid-Core-i7-2600-host.xml | 14 +- .../x86_64-cpuid-Core-i7-2600-json.xml | 4 +- ...6_64-cpuid-Core-i7-2600-xsaveopt-guest.xml | 14 +- ...86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 14 +- ...86_64-cpuid-Core-i7-2600-xsaveopt-json.xml | 4 +- .../x86_64-cpuid-Core-i7-3520M-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-3520M-host.xml | 12 +- .../x86_64-cpuid-Core-i7-3740QM-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-3740QM-host.xml | 12 +- .../x86_64-cpuid-Core-i7-3740QM-json.xml | 2 +- .../x86_64-cpuid-Core-i7-3770-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-3770-host.xml | 12 +- .../x86_64-cpuid-Core-i7-3770-json.xml | 2 +- .../x86_64-cpuid-Core-i7-4510U-guest.xml | 16 +- .../x86_64-cpuid-Core-i7-4510U-host.xml | 16 +- .../x86_64-cpuid-Core-i7-4510U-json.xml | 6 +- .../x86_64-cpuid-Core-i7-4600U-guest.xml | 16 +- .../x86_64-cpuid-Core-i7-4600U-host.xml | 16 +- .../x86_64-cpuid-Core-i7-4600U-json.xml | 6 +- .../x86_64-cpuid-Core-i7-5600U-arat-guest.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-arat-host.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-arat-json.xml | 6 +- .../x86_64-cpuid-Core-i7-5600U-guest.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-host.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-ibrs-guest.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-ibrs-host.xml | 16 +- .../x86_64-cpuid-Core-i7-5600U-ibrs-json.xml | 6 +- .../x86_64-cpuid-Core-i7-5600U-json.xml | 6 +- .../x86_64-cpuid-Core-i7-7600U-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-7600U-host.xml | 12 +- .../x86_64-cpuid-Core-i7-7600U-json.xml | 2 +- .../x86_64-cpuid-Core-i7-7700-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-7700-host.xml | 12 +- .../x86_64-cpuid-Core-i7-7700-json.xml | 2 +- .../x86_64-cpuid-Core-i7-8550U-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-8550U-host.xml | 12 +- .../x86_64-cpuid-Core-i7-8550U-json.xml | 8 +- .../x86_64-cpuid-Core-i7-8700-guest.xml | 12 +- .../x86_64-cpuid-Core-i7-8700-host.xml | 12 +- .../x86_64-cpuid-Core-i7-8700-json.xml | 2 +- .../x86_64-cpuid-Core2-E6850-guest.xml | 14 +- .../x86_64-cpuid-Core2-E6850-host.xml | 14 +- .../x86_64-cpuid-Core2-E6850-json.xml | 4 +- .../x86_64-cpuid-Core2-Q9500-guest.xml | 14 +- .../x86_64-cpuid-Core2-Q9500-host.xml | 14 +- .../x86_64-cpuid-EPYC-7502-32-Core-guest.xml | 2 +- .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 2 +- .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 2 +- .../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 2 +- ..._64-cpuid-EPYC-7601-32-Core-ibpb-guest.xml | 2 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 2 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-json.xml | 2 +- .../x86_64-cpuid-FX-8150-guest.xml | 8 +- .../cputestdata/x86_64-cpuid-FX-8150-host.xml | 8 +- ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 2 +- ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 2 +- .../x86_64-cpuid-Ice-Lake-Server-guest.xml | 12 +- .../x86_64-cpuid-Ice-Lake-Server-host.xml | 12 +- .../x86_64-cpuid-Ice-Lake-Server-json.xml | 2 +- .../x86_64-cpuid-Opteron-1352-guest.xml | 12 +- .../x86_64-cpuid-Opteron-1352-host.xml | 12 +- .../x86_64-cpuid-Opteron-2350-guest.xml | 12 +- .../x86_64-cpuid-Opteron-2350-host.xml | 12 +- .../x86_64-cpuid-Opteron-2350-json.xml | 10 +- .../x86_64-cpuid-Opteron-6234-guest.xml | 8 +- .../x86_64-cpuid-Opteron-6234-host.xml | 8 +- .../x86_64-cpuid-Opteron-6234-json.xml | 8 +- .../x86_64-cpuid-Opteron-6282-guest.xml | 8 +- .../x86_64-cpuid-Opteron-6282-host.xml | 8 +- .../x86_64-cpuid-Pentium-P6100-guest.xml | 14 +- .../x86_64-cpuid-Pentium-P6100-host.xml | 14 +- .../x86_64-cpuid-Phenom-B95-guest.xml | 12 +- .../x86_64-cpuid-Phenom-B95-host.xml | 16 +- .../x86_64-cpuid-Phenom-B95-json.xml | 12 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 2 +- ...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 2 +- ...6_64-cpuid-Ryzen-9-3900X-12-Core-guest.xml | 2 +- ...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml | 2 +- .../x86_64-cpuid-Xeon-5110-guest.xml | 14 +- .../x86_64-cpuid-Xeon-5110-host.xml | 14 +- .../x86_64-cpuid-Xeon-E3-1225-v5-guest.xml | 12 +- .../x86_64-cpuid-Xeon-E3-1225-v5-host.xml | 12 +- .../x86_64-cpuid-Xeon-E3-1225-v5-json.xml | 2 +- .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 12 +- .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 12 +- .../x86_64-cpuid-Xeon-E3-1245-v5-json.xml | 2 +- .../x86_64-cpuid-Xeon-E5-2609-v3-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2609-v3-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2609-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2623-v4-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2623-v4-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2623-v4-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2630-v3-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2630-v3-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2630-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2630-v4-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2630-v4-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2630-v4-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2650-guest.xml | 14 +- .../x86_64-cpuid-Xeon-E5-2650-host.xml | 14 +- .../x86_64-cpuid-Xeon-E5-2650-json.xml | 4 +- .../x86_64-cpuid-Xeon-E5-2650-v3-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2650-v3-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2650-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2650-v4-host.xml | 16 +- .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 6 +- .../x86_64-cpuid-Xeon-E7-4820-guest.xml | 14 +- .../x86_64-cpuid-Xeon-E7-4820-host.xml | 14 +- .../x86_64-cpuid-Xeon-E7-4820-json.xml | 4 +- .../x86_64-cpuid-Xeon-E7-4830-guest.xml | 14 +- .../x86_64-cpuid-Xeon-E7-4830-host.xml | 14 +- .../x86_64-cpuid-Xeon-E7-4830-json.xml | 4 +- .../x86_64-cpuid-Xeon-E7-8890-v3-guest.xml | 16 +- .../x86_64-cpuid-Xeon-E7-8890-v3-host.xml | 16 +- .../x86_64-cpuid-Xeon-E7-8890-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E7540-guest.xml | 14 +- .../x86_64-cpuid-Xeon-E7540-host.xml | 14 +- .../x86_64-cpuid-Xeon-E7540-json.xml | 4 +- .../x86_64-cpuid-Xeon-Gold-5115-guest.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-5115-host.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-5115-json.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6130-guest.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-6130-host.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-6130-json.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6148-guest.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-6148-host.xml | 12 +- .../x86_64-cpuid-Xeon-Gold-6148-json.xml | 2 +- .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 12 +- .../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 12 +- .../x86_64-cpuid-Xeon-Platinum-8268-json.xml | 2 +- .../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 12 +- .../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 12 +- .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 8 +- .../x86_64-cpuid-Xeon-W3520-guest.xml | 14 +- .../x86_64-cpuid-Xeon-W3520-host.xml | 14 +- .../x86_64-cpuid-Xeon-W3520-json.xml | 4 +- .../x86_64-cpuid-Xeon-X5460-guest.xml | 14 +- .../x86_64-cpuid-Xeon-X5460-host.xml | 14 +- ...id-baseline-Broadwell-IBRS+Cascadelake.xml | 6 +- ..._64-cpuid-baseline-Cascadelake+Icelake.xml | 2 +- ...puid-baseline-Cascadelake+Skylake-IBRS.xml | 2 +- ..._64-cpuid-baseline-Cascadelake+Skylake.xml | 2 +- ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 8 +- ...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 2 +- .../x86_64-cpuid-baseline-Haswell+Skylake.xml | 6 +- ...-baseline-Haswell-noTSX-IBRS+Broadwell.xml | 6 +- ...seline-Haswell-noTSX-IBRS+Skylake-IBRS.xml | 6 +- ...id-baseline-Haswell-noTSX-IBRS+Skylake.xml | 6 +- ...4-cpuid-baseline-Skylake-Client+Server.xml | 2 +- .../x86_64-host+guest,model486-result.xml | 18 +- .../x86_64-host+guest,models-result.xml | 4 +- ..._64-host+host+host-model,models-result.xml | 12 +- .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 8 +- .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 6 +- tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 8 +- .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 8 +- .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 6 +- tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 8 +- .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 6 +- .../qemu_7.2.0-tcg.x86_64+hvf.xml | 6 +- .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 6 +- .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 6 +- ...-host-model-fallback-kvm.x86_64-4.2.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-5.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-4.2.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-5.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-5.1.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-5.2.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-6.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-6.1.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-6.2.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-7.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-7.1.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-7.2.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-8.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-8.1.0.args | 2 +- ...host-model-fallback-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-4.2.0.args | 2 +- .../cpu-host-model-kvm.x86_64-5.0.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-4.2.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-5.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-4.2.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-5.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-5.1.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-5.2.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-6.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-6.1.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-6.2.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-7.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-7.1.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-7.2.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-8.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-8.1.0.args | 2 +- ...st-model-nofallback-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-tcg.x86_64-4.2.0.args | 2 +- .../cpu-host-model-tcg.x86_64-5.0.0.args | 2 +- .../cpu-host-model-tcg.x86_64-5.1.0.args | 2 +- .../cpu-host-model-tcg.x86_64-5.2.0.args | 2 +- .../cpu-host-model-tcg.x86_64-6.0.0.args | 2 +- .../cpu-host-model-tcg.x86_64-6.1.0.args | 2 +- .../cpu-host-model-tcg.x86_64-6.2.0.args | 2 +- .../cpu-host-model-tcg.x86_64-7.0.0.args | 2 +- .../cpu-host-model-tcg.x86_64-7.1.0.args | 2 +- .../cpu-host-model-tcg.x86_64-7.2.0.args | 2 +- .../cpu-host-model-tcg.x86_64-8.0.0.args | 2 +- .../cpu-host-model-tcg.x86_64-8.1.0.args | 2 +- .../cpu-host-model-tcg.x86_64-latest.args | 2 +- 251 files changed, 1881 insertions(+), 1577 deletions(-) -- 2.43.0

2 9

[PATCH 0/9] docs: Various fixes, mostly around :since: tags
by Andrea Bolognani 20 Feb '24

20 Feb '24

The way we use :since: is awfully inconsistent. This series doesn't try to fix everything, but takes care of at least a few low-hanging fruits plus a bunch of odds and ends. Abridged version, with the full one available from https://gitlab.com/abologna/libvirt/-/commits/docs-rst-since Andrea Bolognani (9): docs: Format lists of files better docs: Remove unnecessary whitespace docs: Fix list of values docs: Don't use "line blocks" docs: Fix a few weird :since: tags docs: Leave kernel version out of :since: docs: Rewrite a few awkward sections docs: Other fixes to :since: tags syntax-check: Validate :since: tags build-aux/syntax-check.mk | 5 + docs/api_extension.rst | 27 +- docs/bugs.rst | 14 +- docs/drvbhyve.rst | 30 +- docs/drvesx.rst | 19 +- docs/drvnodedev.rst | 2 +- docs/drvqemu.rst | 2 +- docs/drvxen.rst | 2 +- docs/firewall.rst | 23 +- docs/formatcaps.rst | 8 +- docs/formatdomain.rst | 510 ++++++++++++++++--------------- docs/formatnetwork.rst | 81 ++--- docs/formatnetworkport.rst | 2 +- docs/formatnode.rst | 6 +- docs/formatnwfilter.rst | 143 ++++----- docs/formatsecret.rst | 10 +- docs/formatsnapshot.rst | 4 +- docs/formatstorage.rst | 29 +- docs/formatstorageencryption.rst | 8 +- docs/hooks.rst | 168 +++++----- 20 files changed, 563 insertions(+), 530 deletions(-) -- 2.43.2

2 10

[PATCH v2] virsh-completer: modify and fix bug in virshPoolTypeCompleter, now used for more commands
by Adam Julis 20 Feb '24

20 Feb '24

Signed-off-by: Adam Julis <ajulis(a)redhat.com> --- v2: - instead new completer is used already existing virshPoolTypeCompleter - added flag VIRSH_POOL_TYPE_COMPLETER_COMMA for the completer - fixed bug in pool-list --type command v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K6G… tools/virsh-completer-domain.h | 4 ++++ tools/virsh-completer-pool.c | 14 +++++++++----- tools/virsh-pool.c | 3 +++ 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/tools/virsh-completer-domain.h b/tools/virsh-completer-domain.h index 27cf963912..fe4af07937 100644 --- a/tools/virsh-completer-domain.h +++ b/tools/virsh-completer-domain.h @@ -31,6 +31,10 @@ enum { VIRSH_DOMAIN_INTERFACE_COMPLETER_MAC = 1 << 0, /* Return just MACs */ }; +enum { + VIRSH_POOL_TYPE_COMPLETER_COMMA = 1 << 0, +}; + char ** virshDomainInterfaceCompleter(vshControl *ctl, const vshCmd *cmd, diff --git a/tools/virsh-completer-pool.c b/tools/virsh-completer-pool.c index 0600394411..abad0fca1b 100644 --- a/tools/virsh-completer-pool.c +++ b/tools/virsh-completer-pool.c @@ -93,13 +93,17 @@ virshPoolTypeCompleter(vshControl *ctl, g_auto(GStrv) tmp = NULL; const char *type_str = NULL; - virCheckFlags(0, NULL); - - if (vshCommandOptStringQuiet(ctl, cmd, "type", &type_str) < 0) - return NULL; + virCheckFlags(VIRSH_POOL_TYPE_COMPLETER_COMMA, NULL); tmp = virshEnumComplete(VIR_STORAGE_POOL_LAST, virStoragePoolTypeToString); - return virshCommaStringListComplete(type_str, (const char **)tmp); + if (flags & VIRSH_POOL_TYPE_COMPLETER_COMMA){ + if (vshCommandOptStringQuiet(ctl, cmd, "type", &type_str) < 0) + return NULL; + + return virshCommaStringListComplete(type_str, (const char **)tmp); + } + + return g_steal_pointer(&tmp); } diff --git a/tools/virsh-pool.c b/tools/virsh-pool.c index 36f00cf643..6936406087 100644 --- a/tools/virsh-pool.c +++ b/tools/virsh-pool.c @@ -1088,6 +1088,7 @@ static const vshCmdOptDef opts_pool_list[] = { }, {.name = "type", .type = VSH_OT_STRING, + .completer_flags = VIRSH_POOL_TYPE_COMPLETER_COMMA, .completer = virshPoolTypeCompleter, .help = N_("only list pool of specified type(s) (if supported)") }, @@ -1414,6 +1415,7 @@ static const vshCmdOptDef opts_find_storage_pool_sources_as[] = { {.name = "type", .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, + .completer = virshPoolTypeCompleter, .help = N_("type of storage pool sources to find") }, {.name = "host", @@ -1501,6 +1503,7 @@ static const vshCmdOptDef opts_find_storage_pool_sources[] = { {.name = "type", .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, + .completer = virshPoolTypeCompleter, .help = N_("type of storage pool sources to discover") }, {.name = "srcSpec", -- 2.43.0

2 2

[PATCH 0/8] qemuMigrationDstPrepareStorage: Refactor and fix for VDPA storage
by Peter Krempa 20 Feb '24

20 Feb '24

Peter Krempa (8): qemuMigrationDstPrepareStorage: Use 'switch' statement to include all storage types qemuMigrationDstPrepareStorage: Properly consider path for 'vdpa' devices qemuMigrationDstPrecreateDisk: Refactor cleanup qemuMigrationDstPrepareStorage: Move block device specific logic qemuMigrationDstPrepareStorage: Rework storage existence check qemuMigrationDstPrepareStorage: Reject migration into 'dir' and 'vhost-user' types qemuMigrationDstPrepareStorage: Move assumption that 'network' disks always exist qemuMigrationDstPrepareStorage: Annotate that existance of 'volume' disks is checked elswhere src/qemu/qemu_migration.c | 117 +++++++++++++++++++++----------------- 1 file changed, 66 insertions(+), 51 deletions(-) -- 2.43.0

2 9

[PATCH] domain_validate: Account for NVDIMM label size properly when checking for memory conflicts
by Michal Privoznik 20 Feb '24

20 Feb '24

As of v9.8.0-rc1~7 we check whether two <memory/> devices don't overlap (since we allow setting where a <memory/> device should be mapped to). We do this pretty straightforward, by comparing start and end address of each <memory/> device combination. But since only the start address is given (an exposed in the XML), the end address is computed trivially as: start + mem->size * 1024 And for majority of memory device types this works. Except for NVDIMMs. For them the <memory/> device consists of two separate regions: 1) actual memory device, and 2) label. Label is where NVDIMM stores some additional information like namespaces partition and so on. But it's not mapped into the guest the same way as actual memory device. In fact, mem->size is a sum of both actual memory device and label sizes. And to make things a bit worse, both sizes are subject to alignment (either the alignsize value specified in XML, or system page size if not specified in XML). Therefore, to get the size of actual memory device we need to take mem->size and substract label size rounded up to alignment. If we don't do this we report there's an overlap between two NVDIMMs even when in reality there's none. Resolves: https://issues.redhat.com/browse/RHEL-4452?focusedId=23805174#comment-23805… Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_validate.c | 50 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 46479f10f2..5a9398b545 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -2225,6 +2225,52 @@ virDomainHostdevDefValidate(const virDomainHostdevDef *hostdev) } +/** + * virDomainMemoryGetMappedSize: + * @mem: memory device definition + * + * For given memory device definition (@mem) calculate size mapped into + * the guest. This is usually mem->size, except for NVDIMM where its + * label is mapped elsewhere. + * + * Returns: Number of bytes a memory device takes when mapped into a + * guest. + */ +static unsigned long long +virDomainMemoryGetMappedSize(const virDomainMemoryDef *mem) +{ + unsigned long long ret = mem->size; + + if (mem->model == VIR_DOMAIN_MEMORY_MODEL_NVDIMM) { + unsigned long long alignsize = mem->source.nvdimm.alignsize; + unsigned long long labelsize = 0; + + /* For NVDIMM the situation is a bit more complicated. Firstly, + * its <label/> is not mapped as a part of memory device, so we + * must subtract label size from NVDIMM size. Secondly, label is + * also subject to alignment so we need to round it up before + * subtraction. */ + + if (alignsize == 0) { + long pagesize = virGetSystemPageSizeKB(); + + /* If no alignment is specified in the XML, fallback to + * system page size alignment. */ + if (pagesize > 0) + alignsize = pagesize; + } + + if (alignsize > 0) { + labelsize = VIR_ROUND_UP(mem->target.nvdimm.labelsize, alignsize); + + ret -= labelsize; + } + } + + return ret * 1024; +} + + static int virDomainMemoryDefCheckConflict(const virDomainMemoryDef *mem, const virDomainDef *def) @@ -2259,7 +2305,7 @@ virDomainMemoryDefCheckConflict(const virDomainMemoryDef *mem, } /* thisStart and thisEnd are in bytes, mem->size in kibibytes */ - thisEnd = thisStart + mem->size * 1024; + thisEnd = thisStart + virDomainMemoryGetMappedSize(mem); for (i = 0; i < def->nmems; i++) { const virDomainMemoryDef *other = def->mems[i]; @@ -2316,7 +2362,7 @@ virDomainMemoryDefCheckConflict(const virDomainMemoryDef *mem, if (thisStart == 0 || otherStart == 0) continue; - otherEnd = otherStart + other->size * 1024; + otherEnd = otherStart + virDomainMemoryGetMappedSize(other); if ((thisStart <= otherStart && thisEnd > otherStart) || (otherStart <= thisStart && otherEnd > thisStart)) { -- 2.43.0

2 1

[PATCH] NEWS: Announce support for /dev/userfaultfd
by Jiri Denemark 19 Feb '24

19 Feb '24

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 15b0da31b6..cf9692130a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,12 @@ v10.1.0 (unreleased) * **New features** + * qemu: Add support for /dev/userfaultfd + + On hosts with new enough kernel which supports /dev/userfaultfd libvirt will + now automatically grant QEMU access to this device. It's no longer needed to + set vm.unprivileged_userfaultfd sysctl. + * qemu: Support clusters in CPU topology It is now possible to configure the guest CPU topology to use clusters. -- 2.43.2

2 1

[PATCH 0/2] Make it visible that not all tests can be run
by Martin Kletzander 19 Feb '24

19 Feb '24

Inspired by: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/TSK… Martin Kletzander (2): build: Split optional programs into test and rest build: Let users know not all tests might run meson.build | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) -- 2.43.1

3 6

[PATCH 0/1] Expose availability of SEV-ES
by Takashi Kajinami 19 Feb '24

19 Feb '24

This introduces the new "model" field in sev elements so that clients can check whether SEV-ES, the 2nd generation of AMD SEV, is available in the taget hyprvisor. Takashi Kajinami (1): Expose available AMD SEV models in domain capabilities src/conf/domain_capabilities.c | 2 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 7 +++ src/conf/domain_conf.h | 8 ++++ src/qemu/qemu_capabilities.c | 78 ++++++++++++++++++++++++---------- 5 files changed, 74 insertions(+), 22 deletions(-) -- 2.43.0

2 4

Plans for 10.1.0 release (freeze on Monday 26 Feb)
by Jiri Denemark 19 Feb '24

19 Feb '24

We are getting close to 10.1.0 release of libvirt. To aim for the release on Friday 01 Mar I suggest entering the freeze on Monday 26 Feb and tagging RC2 on Wednesday 28 Feb. I hope this works for everyone. Jirka

1 0