April 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

Question about SEV* guests and automatic firmware selection
by Jim Fehlig 31 Jul '25

31 Jul '25

Hi All, While investigating an internal bug report, we noticed that a minimal firmware auto-selection configuration along with SEV* fails to find a match. E.g. the following config <domain type="kvm"> <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <boot dev="hd"/> </os> <launchSecurity type="sev"> <policy>0x07</policy> </launchSecurity> ... </domain> Fails with "Unable to find 'efi' firmware that is compatible with the current configuration". A firmware that should match has the following json description { "description": "UEFI firmware for x86_64, with AMD SEV", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "acpi-s4", "amd-sev", "amd-sev-es", "amd-sev-snp", "verbose-dynamic" ], "tags": [ ] } Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend the above config with <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <loader stateless="yes"/> <boot dev="hd"/> </os> Being unfamiliar with the firmware auto-selection code, I tried the below naive hack, which only led to test failures and the subsequent runtime error "unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin". Should auto-selection work with the minimal config, or is it expected that user also specify a stateless firmware? Regards, Jim diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 2d0ec0b4fa..660b74141a 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1293,15 +1293,17 @@ qemuFirmwareMatchDomain(const virDomainDef *def, return false; } - if (loader && loader->stateless == VIR_TRISTATE_BOOL_YES) { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { - VIR_DEBUG("Discarding loader without stateless flash"); - return false; - } - } else { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) { - VIR_DEBUG("Discarding loader without split flash"); - return false; + if (loader) { + if (loader->stateless == VIR_TRISTATE_BOOL_YES) { + if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { + VIR_DEBUG("Discarding loader without stateless flash"); + return false; + } + } else if (loader->stateless == VIR_TRISTATE_BOOL_NO) { + if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) { + VIR_DEBUG("Discarding loader without split flash"); + return false; + } } }

3 6

[PATCH 0/4] Allow xml-configured coredump format on VM crash
by Nikolai Barybin 08 Jul '25

08 Jul '25

When libvirt processes VM crash event it always dumps core in raw format. This series makes it possible to configure dump format via domain xml. This would be especcialy helpful for Windows guests, because it requires a lot effort to convert raw dump into wingdb. Nikolai Barybin (4): conf: schemas: add coredump_format element to events section src: conf: add parsing/formatting for 'coredump_format' value qemu: use configurable dump format in doCoreDumpToAutoDumpPath() docs: formatdomain: document 'coredump_format' element docs/formatdomain.rst | 9 +++++ src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 2 + src/conf/schemas/domaincommon.rng | 19 +++++++++ src/libvirt_private.syms | 2 + src/qemu/qemu_driver.c | 2 +- 6 files changed, 97 insertions(+), 1 deletion(-) -- 2.43.5

3 8

[PATCH 0/2] network: support NAT networking for FreeBSD/pf
by Roman Bogorodskiy 02 Jul '25

02 Jul '25

This series implements NAT networks support for FreeBSD using the Packet Filter (pf) firewall. The commit messages provide high-level details and limitations of the current implementation, and I'll use this cover letter to provide some more technical details and describe testing I have performed for this change. Libvirt FreeBSD/pf NAT testing For two networks: virsh # net-dumpxml default <network> <name>default</name> <uuid>68cd5419-9fda-4cf0-9ac6-2eb9c1ba41ed</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:db:0e:e5'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network> virsh # net-dumpxml natnet <network> <name>natnet</name> <uuid>d3c59659-3ceb-4482-a625-1f839a54429c</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr1' stp='on' delay='0'/> <mac address='52:54:00:0a:fc:1d'/> <ip address='10.0.100.1' netmask='255.255.255.0'> <dhcp> <range start='10.0.100.2' end='10.0.100.254'/> </dhcp> </ip> </network> virsh # The following rules are generated: $ sudo pfctl -a '*' -sn nat-anchor "libvirt/*" all { nat-anchor "default" all { nat pass on re0 inet from 192.168.122.0/24 to <natdst> -> (re0) port 1024:65535 round-robin } nat-anchor "natnet" all { nat pass on re0 inet from 10.0.100.0/24 to <natdst> -> (re0) port 1024:65535 round-robin } } $ $ sudo pfctl -a 'libvirt/default' -t natdst -T show 0.0.0.0/0 !192.168.122.0/24 !224.0.0.0/24 !255.255.255.255 $ sudo pfctl -a 'libvirt/natnet' -t natdst -T show 0.0.0.0/0 !10.0.100.0/24 !224.0.0.0/24 !255.255.255.255 $ $ sudo pfctl -a '*' -sr scrub all fragment reassemble anchor "libvirt/*" all { anchor "default" all { pass quick on virbr0 inet from 192.168.122.0/24 to 192.168.122.0/24 flags S/SA keep state pass quick on virbr0 inet from 192.168.122.0/24 to 224.0.0.0/24 flags S/SA keep state pass quick on virbr0 inet from 192.168.122.0/24 to 255.255.255.255 flags S/SA keep state block drop on virbr0 all } anchor "natnet" all { pass quick on virbr1 inet from 10.0.100.0/24 to 10.0.100.0/24 flags S/SA keep state pass quick on virbr1 inet from 10.0.100.0/24 to 224.0.0.0/24 flags S/SA keep state pass quick on virbr1 inet from 10.0.100.0/24 to 255.255.255.255 flags S/SA keep state block drop on virbr1 all } } pass all flags S/SA keep state $ Create two guests attached to the "default" network, vmA and vmB. vmA $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:67:eb:de brd ff:ff:ff:ff:ff:ff inet 192.168.122.92/24 brd 192.168.122.255 scope global dynamic noprefixroute enp0s4 valid_lft 1082sec preferred_lft 1082sec inet6 fe80::5054:ff:fe67:ebde/64 scope link noprefixroute valid_lft forever preferred_lft forever vmA $ vmB $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:d2:8b:41 brd ff:ff:ff:ff:ff:ff inet 192.168.122.154/24 metric 100 brd 192.168.122.255 scope global dynamic enp0s4 valid_lft 1040sec preferred_lft 1040sec inet6 fe80::5054:ff:fed2:8b41/64 scope link valid_lft forever preferred_lft forever vmB $ Test NAT rules: vmA $ ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=14.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=10.7 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.1 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 10.099/11.835/14.710/2.047 ms vmA $ vmB $ ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.1 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=11.0 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.4 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 10.434/12.198/15.113/2.075 ms vmB $ vmA $ curl wttr.in/?0Q Fog _ - _ - _ - +4(1) °C _ - _ - _ ↙ 11 km/h _ - _ - _ - 0 km 0.0 mm vmA $ vmB $ curl wttr.in/?0Q Fog _ - _ - _ - +4(1) °C _ - _ - _ ↙ 11 km/h _ - _ - _ - 0 km 0.0 mm vmB $ Inter-VM connectivity: vmA $ ping -c 3 192.168.122.154 PING 192.168.122.154 (192.168.122.154) 56(84) bytes of data. 64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.253 ms 64 bytes from 192.168.122.154: icmp_seq=2 ttl=64 time=0.226 ms 64 bytes from 192.168.122.154: icmp_seq=3 ttl=64 time=0.269 ms --- 192.168.122.154 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2042ms rtt min/avg/max/mdev = 0.226/0.249/0.269/0.017 ms vmA $ vmA $ ssh 192.168.122.154 uname novel(a)192.168.122.154's password: Linux vmA $ Multicast test: vmA $ iperf -s -u -B 224.0.0.1 -i 1 ------------------------------------------------------------ Server listening on UDP port 5001 Joining multicast group 224.0.0.1 Server set to single client traffic mode (per multicast receive) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 1] local 224.0.0.1 port 5001 connected with 192.168.122.154 port 36963 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 1] 0.00-1.00 sec 131 KBytes 1.07 Mbits/sec 0.030 ms 0/91 (0%) [ 1] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.022 ms 0/89 (0%) [ 1] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.021 ms 0/89 (0%) [ 1] 0.00-3.02 sec 389 KBytes 1.06 Mbits/sec 0.026 ms 0/271 (0%) vmB $ iperf -c 224.0.0.1 -u -T 32 -t 3 -i 1 ------------------------------------------------------------ Client connecting to 224.0.0.1, UDP port 5001 Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.122.154 port 36963 connected with 224.0.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.0000-1.0000 sec 131 KBytes 1.07 Mbits/sec [ 1] 1.0000-2.0000 sec 128 KBytes 1.05 Mbits/sec [ 1] 2.0000-3.0000 sec 128 KBytes 1.05 Mbits/sec [ 1] 0.0000-3.0173 sec 389 KBytes 1.06 Mbits/sec [ 1] Sent 272 datagrams vmB $ Broadcast test: vmA $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 net.ipv4.icmp_echo_ignore_broadcasts = 0 vmA $ vmB $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 net.ipv4.icmp_echo_ignore_broadcasts = 0 vmB $ host $ ping 192.168.122.255 PING 192.168.122.255 (192.168.122.255): 56 data bytes 64 bytes from 192.168.122.154: icmp_seq=0 ttl=64 time=0.199 ms 64 bytes from 192.168.122.92: icmp_seq=0 ttl=64 time=0.227 ms (DUP!) 64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.209 ms 64 bytes from 192.168.122.92: icmp_seq=1 ttl=64 time=0.235 ms (DUP!) ^C --- 192.168.122.255 ping statistics --- 2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet loss round-trip min/avg/max/stddev = 0.199/0.218/0.235/0.014 ms This testing does not cover any negative scenarios which are probably not that important at this point. Roman Bogorodskiy (2): network: bridge_driver: add BSD implementation network: introduce Packet Filter firewall backend meson.build | 2 + po/POTFILES | 2 + src/network/bridge_driver_bsd.c | 107 +++++++++ src/network/bridge_driver_conf.c | 8 + src/network/bridge_driver_linux.c | 2 + src/network/bridge_driver_platform.c | 2 + src/network/meson.build | 1 + src/network/network_pf.c | 327 +++++++++++++++++++++++++++ src/network/network_pf.h | 26 +++ src/util/virfirewall.c | 4 +- src/util/virfirewall.h | 2 + 11 files changed, 482 insertions(+), 1 deletion(-) create mode 100644 src/network/bridge_driver_bsd.c create mode 100644 src/network/network_pf.c create mode 100644 src/network/network_pf.h -- 2.49.0

2 7

[PATCH 0/4] USB hostdev: allow addressing by port
by Maximilian Martin 27 Jun '25

27 Jun '25

This resubmission splits up the previous patch into multiple patches and incorporates review comments from Michal Prívozník. Currently, only vendor/product and bus/device matching are supported for USB host devices. Neither of these provide a stable and persistent way of assigning a guest a specific host device. Vendor/product can be ambiguous. Device numbers change on every enumeration. This patch adds a bus/port matching, which allows a specific port on the host to be specified using the dotted notation found in Linux's "devpath" sysfs attribute. This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7U3… Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513 Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de> Maximilian Martin (4): virusb test data: add devpath files for port addressing domain_conf, virhostdev, virusb, virusb test: add bus/port matching schema: add USB port attribute docs: add description for USB port matching docs/formatdomain.rst | 29 ++-- src/conf/domain_conf.c | 69 +++++++- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 11 +- src/hypervisor/virhostdev.c | 131 +++++++++------ src/libvirt_private.syms | 2 - src/util/virusb.c | 156 ++++++------------ src/util/virusb.h | 32 ++-- tests/virusbtest.c | 149 ++++++++++++----- .../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.4/devpath | 1 + .../sys_bus_usb/devices/1-1.5.5/devpath | 1 + .../sys_bus_usb/devices/1-1.5.6/devpath | 1 + .../sys_bus_usb/devices/1-1.5/devpath | 1 + .../sys_bus_usb/devices/1-1.6/devpath | 1 + .../sys_bus_usb/devices/1-1/devpath | 1 + .../sys_bus_usb/devices/2-1.2/devpath | 1 + .../sys_bus_usb/devices/2-1/devpath | 1 + .../sys_bus_usb/devices/usb1/devpath | 1 + .../sys_bus_usb/devices/usb2/devpath | 1 + .../sys_bus_usb/devices/usb3/devpath | 1 + .../sys_bus_usb/devices/usb4/devpath | 1 + 24 files changed, 351 insertions(+), 244 deletions(-) create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath -- 2.39.5

3 16

[PATCH 0/3] qemu: Replace usb-storage with usb-bot
by Akihiko Odaki 12 Jun '25

12 Jun '25

usb-storage is a compound device that automatically creates a USB mass storage device and a SCSI device as its backend. Unfortunately it lacks some configuration options that are usually present with a SCSI device, and cannot represent CD-ROM in particular. Replace usb-storage with usb-bot, which can be combined with a manually created SCSI device. libvirt will configure the SCSI device in a way identical with how QEMU does for usb-storage except that now it respects a configuration option to represent CD-ROM. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368 Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Akihiko Odaki (3): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT qemu: Replace usb-storage with usb-bot qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE src/qemu/qemu_alias.c | 3 +- src/qemu/qemu_capabilities.c | 19 +- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_command.c | 55 +++++- src/qemu/qemu_command.h | 5 + src/qemu/qemu_hotplug.c | 34 +++- src/qemu/qemu_validate.c | 4 +- .../qemucapabilitiesdata/caps_10.0.0_s390x.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 2 +- .../caps_10.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 2 +- .../caps_5.2.0_aarch64.replies | 174 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_ppc64.replies | 178 +++++------------- tests/qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 2 +- .../caps_5.2.0_riscv64.replies | 170 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_x86_64.replies | 190 +++++-------------- tests/qemucapabilitiesdata/caps_5.2.0_x86_64.xml | 2 +- .../caps_6.0.0_aarch64.replies | 172 ++++------------- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.0.0_x86_64.replies | 188 +++++-------------- tests/qemucapabilitiesdata/caps_6.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_6.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.1.0_x86_64.xml | 2 +- .../caps_6.2.0_aarch64.replies | 178 ++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 2 +- .../caps_7.0.0_aarch64+hvf.replies | 182 +++++------------- .../caps_7.0.0_aarch64+hvf.xml | 2 +- .../caps_7.0.0_aarch64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_7.2.0_ppc.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 +- .../caps_7.2.0_x86_64+hvf.replies | 206 +++++---------------- .../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 2 +- .../qemucapabilitiesdata/caps_7.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 2 +- .../caps_8.0.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_8.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 2 +- .../caps_8.2.0_aarch64.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_armv7l.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 2 +- .../caps_8.2.0_loongarch64.replies | 186 ++++--------------- .../caps_8.2.0_loongarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 2 +- .../caps_9.1.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 2 +- tests/qemuhotplugtest.c | 8 +- .../qemuxmlconfdata/disk-cache.x86_64-latest.args | 3 +- .../disk-cdrom-bus-other.x86_64-latest.args | 3 +- .../disk-device-removable.x86_64-latest.args | 3 +- .../disk-usb-device.x86_64-latest.args | 3 +- 84 files changed, 1689 insertions(+), 5346 deletions(-) --- base-commit: e5299ddf86121d3c792ca271ffcb54900eb19dc3 change-id: 20250304-bot-5d84aa3a5cfe Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

4 11

[PATCH v3 0/6] qemu: acpi-generic-initiator support
by Andrea Righi 16 May '25

16 May '25

= Overview = This patch set introduces support for acpi-generic-initiator devices, supported by QEMU [1]. The acpi-generic-initiator object is required to support Multi-Instance GPU (MIG) configurations on NVIDIA GPUs [2]. MIG enables partitioning of GPU resources into multiple isolated instances, each requiring a dedicated NUMA node definition. = Implementation = This patch set implements the libvirt counterpart to the QEMU feature, enabling users to configure acpi-generic-initiator objects within libvirt domain XML. This includes: - adding XML syntax to define acpi-generic-initiator objects, - resolving the acpi-generic-initiator definitions into the proper QEMU command-line arguments, - ensuring compatibility with existing NUMA configuration. = Example = - Domain XML: ``` ... <cpu mode='host-passthrough' check='none'> <numa> <cell id='0' cpus='0-15' memory='8388608' unit='KiB'/> <cell id='1' memory='0' unit='KiB'/> <cell id='2' memory='0' unit='KiB'/> <cell id='3' memory='0' unit='KiB'/> <cell id='4' memory='0' unit='KiB'/> <cell id='5' memory='0' unit='KiB'/> <cell id='6' memory='0' unit='KiB'/> <cell id='7' memory='0' unit='KiB'/> <cell id='8' memory='0' unit='KiB'/> </numa> </cpu> ... <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <acpi-generic-initiator> <alias name="gi1"/> <pci-dev>hostdev0</pci-dev> <numa-node>1</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi2"/> <pci-dev>hostdev0</pci-dev> <numa-node>2</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi3"/> <pci-dev>hostdev0</pci-dev> <numa-node>3</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi4"/> <pci-dev>hostdev0</pci-dev> <numa-node>4</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi5"/> <pci-dev>hostdev0</pci-dev> <numa-node>5</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi6"/> <pci-dev>hostdev0</pci-dev> <numa-node>6</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi7"/> <pci-dev>hostdev0</pci-dev> <numa-node>7</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi8"/> <pci-dev>hostdev0</pci-dev> <numa-node>8</numa-node> </acpi-generic-initiator> </devices> ``` - Generated QEMU command line options: ``` ... /usr/bin/qemu-system-aarch64 \ ... -object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":8589934592}' \ -numa node,nodeid=0,cpus=0-15,memdev=ram-node0 \ -numa node,nodeid=1 \ -numa node,nodeid=2 \ -numa node,nodeid=3 \ -numa node,nodeid=4 \ -numa node,nodeid=5 \ -numa node,nodeid=6 \ -numa node,nodeid=7 \ -numa node,nodeid=8 \ ... -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}' ... -object acpi-generic-initiator,id=gi1,pci-dev=hostdev0,node=1 \ -object acpi-generic-initiator,id=gi2,pci-dev=hostdev0,node=2 \ -object acpi-generic-initiator,id=gi3,pci-dev=hostdev0,node=3 \ -object acpi-generic-initiator,id=gi4,pci-dev=hostdev0,node=4 \ -object acpi-generic-initiator,id=gi5,pci-dev=hostdev0,node=5 \ -object acpi-generic-initiator,id=gi6,pci-dev=hostdev0,node=6 \ -object acpi-generic-initiator,id=gi7,pci-dev=hostdev0,node=7 \ -object acpi-generic-initiator,id=gi8,pci-dev=hostdev0,node=8 ``` = References = [1] https://lore.kernel.org/all/20231225045603.7654-2-ankita@nvidia.com/ [2] https://www.nvidia.com/en-in/technologies/multi-instance-gpu/ ChangeLog v2 -> v3: - replaced <text/> with proper types in the XML schema - avoid mixing g_free() and VIR_FREE() - use virXMLPropString() instead of looping all XML nodes - report proper errors with virReportError() - use virBufferEscapeString() to process strings passed by the user - fix broken formatting of function headers - misc coding style fixes ChangeLog v1 -> v2: - split parser and driver changes in separate patches - introduce a new qemu capability flag - introduce test in qemuxmlconftest Andrea Righi (6): schema: Introduce acpi-generic-initiator definition conf: Introduce acpi-generic-initiator device qemu: Allow to define NUMA nodes without memory or CPUs assigned qemu: capabilies: Introduce QEMU_CAPS_ACPI_GENERIC_INITIATOR qemu: support acpi-generic-initiator qemu: Add test case for acpi-generic-initiator src/ch/ch_domain.c | 1 + src/conf/domain_conf.c | 159 +++++++++++++++++++++ src/conf/domain_conf.h | 14 ++ src/conf/domain_postparse.c | 1 + src/conf/domain_validate.c | 37 +++++ src/conf/numa_conf.c | 3 + src/conf/schemas/domaincommon.rng | 19 +++ src/conf/virconftypes.h | 2 + src/libxl/libxl_driver.c | 6 + src/lxc/lxc_driver.c | 6 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 49 ++++++- src/qemu/qemu_domain.c | 2 + src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_driver.c | 3 + src/qemu/qemu_hotplug.c | 5 + src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 1 + src/test/test_driver.c | 4 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 1 + .../acpi-generic-initiator.x86_64-latest.args | 55 +++++++ .../acpi-generic-initiator.x86_64-latest.xml | 102 +++++++++++++ tests/qemuxmlconfdata/acpi-generic-initiator.xml | 102 +++++++++++++ tests/qemuxmlconftest.c | 1 + 32 files changed, 581 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.xml

3 12

[PATCH RESEND 0/6] Add support for configuring PCI high memory MMIO size
by Matthew R. Ochs 13 May '25

13 May '25

Resending: Series has been re-based over latest upstream. This patch series adds support for configuring the PCI high memory MMIO window size for aarch64 virt machine types. This feature has been merged into the QEMU upstream master branch [1] and will be available in QEMU 10.0. It allows users to configure the size of the high memory MMIO window above 4GB, which is particularly useful for systems with large amounts of PCI memory requirements. The feature is exposed through the domain XML as a new PCI feature: <features> <pci> <highmem-mmio-size unit='G'>512</highmem-mmio-size> </pci> </features> When enabled, this configures the size of the PCI high memory MMIO window via QEMU's highmem-mmio-size machine property. The feature is only available for aarch64 virt machine types and requires QEMU support. This series depends on [2] and should be applied on top of those patches. For your convenience, this series is also available on Github [3]. [1] https://github.com/qemu/qemu/commit/f10104aeae3a17f181d5bb37b7fd7dad7fe86cba [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4NQ… [3] git fetch https://github.com/nvmochs/libvirt.git pci_highmem_mmio_size Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com> Matthew R. Ochs (6): domain: Add PCI configuration feature infrastructure schema: Add PCI configuration feature schema conf: Add PCI configuration XML parsing and formatting qemu: Add capability for PCI high memory MMIO size qemu: Add command line support for PCI high memory MMIO size tests: Add tests for machine PCI features src/conf/domain_conf.c | 103 ++++++++++++++++++ src/conf/domain_conf.h | 6 + src/conf/schemas/domaincommon.rng | 9 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 6 + src/qemu/qemu_validate.c | 15 +++ .../caps_10.0.0_aarch64.replies | 10 ++ .../caps_10.0.0_aarch64.xml | 1 + ...rch64-virt-machine-pci.aarch64-latest.args | 31 ++++++ ...arch64-virt-machine-pci.aarch64-latest.xml | 30 +++++ .../aarch64-virt-machine-pci.xml | 20 ++++ tests/qemuxmlconftest.c | 2 + 13 files changed, 236 insertions(+) create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.xml -- 2.46.0

3 15

[PATCH v3 0/5] Adding POWER11 CPU Support
by Narayana Murty N 13 May '25

13 May '25

This patch series introduces the necessary changes to support the power11 CPU and power11 host in libvirt. Additionally, it updates the QEMU capabilities with the latest QEMU version v10.0.0-rc2 to include power11 in the capabilities tests.During testing of v2 patches found a bug in qemu which sets wrong default cpu for pre-9.0 machines, that was fixed in qemu v10.0.0-rc2. Patch Summary: Patch 0001: tests: Pin pseries-2.7 tests to the version 7.0. Patch 0002: Fix: qemuhotplugtest Set the cpu version at source as POWER9. Patch 0003: Add capabilities test support for QEMU 10.0.0 on PPC64. Patch 0004: Add POWER11 CPU model support. Patch 0005: Add POWER11 host model support and accept case-insensitive. The corresponding patches for the Linux kernel and QEMU are already upstream. Relevant links are provided below: Linux kernel patches: 1. Linux P11 support: commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode") 2. Linux P11 KVM support: commit 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests") Qemu patches: 3. Qemu P11 support: commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type") 4. Qemu P11 DD02.0 support: commit c0d964076c3e ("target/ppc: Add Power11 DD2.0 processor") 5. Qemu pre-9.0 pseries michines changing default cpu with Qemu commit 1490d0bcdfcb ("ppc/spapr: fix default cpu for pre-9.0 machines."). Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> ---- Changelog: -V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PGSB… *Rebased to top of the tree as I saw some tests were failing with recent commits. -V2:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/JQ5UJFWJG35OFX54RQIDHFUSX3RIYIYP/?sort=thread *Instead of removing pseries-2.7 related tests, they are now pinned to the latest available capabilities version 7.0.0. *patch0003: description explained why the cpu version changed. *change the cpu model name to lower case. *Fixing the hotplugtest by setting the cpu version at source as POWER9 *default CPU change for pseries machines preior to pseries-9.0 tests cases for tcg fixed. * Fixing the compat models check for host CPU names in both lowercase and uppercase. -V1:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4A3IND2QP5CE654XE755ICRZKLUNYXAE/ *Addressed v2 patch readability issues. Narayana Murty N (5): tests: Pin pseries-2.7 tests to the version 7.0 tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests tests: Add capabilities for QEMU 10.0.0 on ppc64 cpu_map: Add POWER11 cpu model support cpu_ppc64: Add POWER11 hostmodel support and accept case insensitive src/cpu/cpu_ppc64.c | 11 +- src/cpu_map/index.xml | 1 + src/cpu_map/meson.build | 1 + src/cpu_map/ppc64_POWER11.xml | 6 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 191 + .../caps_10.0.0_ppc64.replies | 39513 ++++++++++++++++ .../caps_10.0.0_ppc64.xml | 1090 + .../ppc64-modern-bulk-domain.xml | 3 +- .../ppc64-modern-individual-domain.xml | 3 +- .../disk-floppy-pseries.ppc64-latest.xml | 2 +- .../memory-hotplug-nvdimm-ppc64.xml | 3 +- .../memory-hotplug-ppc64-nonuma.xml | 3 + .../panic-pseries.ppc64-latest.args | 2 +- .../panic-pseries.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} | 0 ...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-3.1.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-4.2.ppc64-latest.xml | 2 +- ...ault-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} | 0 ...efault-models.ppc64-latest.abi-update.args | 4 +- ...default-models.ppc64-latest.abi-update.xml | 2 +- ...4-pseries-default-models.ppc64-latest.args | 4 +- ...64-pseries-default-models.ppc64-latest.xml | 2 +- .../ppc64-pseries-graphics.ppc64-latest.args | 4 +- .../ppc64-pseries-graphics.ppc64-latest.xml | 2 +- .../ppc64-pseries-headless.ppc64-latest.args | 4 +- .../ppc64-pseries-headless.ppc64-latest.xml | 2 +- ...eries-minimal.ppc64-latest.abi-update.args | 2 +- ...series-minimal.ppc64-latest.abi-update.xml | 2 +- .../ppc64-pseries-minimal.ppc64-latest.args | 2 +- .../ppc64-pseries-minimal.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 2 +- .../pseries-basic.ppc64-latest.args | 2 +- .../pseries-basic.ppc64-latest.xml | 2 +- .../pseries-console-virtio.ppc64-latest.args | 2 +- .../pseries-console-virtio.ppc64-latest.xml | 2 +- ...eries-cpu-compat-power11.ppc64-latest.args | 31 + ...series-cpu-compat-power11.ppc64-latest.err | 1 + ...series-cpu-compat-power11.ppc64-latest.xml | 29 + .../pseries-cpu-compat-power11.xml | 19 + .../pseries-cpu-le.ppc64-latest.args | 2 +- .../pseries-cpu-le.ppc64-latest.xml | 2 +- .../pseries-features.ppc64-latest.args | 2 +- .../pseries-features.ppc64-latest.xml | 2 +- .../pseries-hostdevs-1.ppc64-latest.args | 2 +- .../pseries-hostdevs-1.ppc64-latest.xml | 2 +- .../pseries-hostdevs-2.ppc64-latest.args | 2 +- .../pseries-hostdevs-2.ppc64-latest.xml | 2 +- .../pseries-hostdevs-3.ppc64-latest.args | 2 +- .../pseries-hostdevs-3.ppc64-latest.xml | 2 +- .../pseries-many-buses-1.ppc64-latest.args | 2 +- .../pseries-many-buses-1.ppc64-latest.xml | 2 +- .../pseries-many-buses-2.ppc64-latest.args | 2 +- .../pseries-many-buses-2.ppc64-latest.xml | 2 +- .../pseries-many-devices.ppc64-latest.args | 2 +- .../pseries-many-devices.ppc64-latest.xml | 2 +- .../pseries-nvram.ppc64-latest.args | 2 +- .../pseries-nvram.ppc64-latest.xml | 2 +- .../pseries-panic-missing.ppc64-latest.args | 2 +- .../pseries-panic-missing.ppc64-latest.xml | 2 +- ...pseries-panic-no-address.ppc64-latest.args | 2 +- .../pseries-panic-no-address.ppc64-latest.xml | 2 +- ...ries-phb-default-missing.ppc64-latest.args | 2 +- ...eries-phb-default-missing.ppc64-latest.xml | 2 +- .../pseries-phb-numa-node.ppc64-latest.args | 2 +- .../pseries-phb-numa-node.ppc64-latest.xml | 2 +- .../pseries-phb-simple.ppc64-latest.args | 6 +- .../pseries-phb-simple.ppc64-latest.xml | 2 +- .../pseries-phb-user-alias.ppc64-latest.args | 6 +- .../pseries-phb-user-alias.ppc64-latest.xml | 2 +- .../pseries-serial-native.ppc64-latest.args | 2 +- .../pseries-serial-native.ppc64-latest.xml | 2 +- .../pseries-serial-pci.ppc64-latest.args | 2 +- .../pseries-serial-pci.ppc64-latest.xml | 2 +- .../pseries-serial-usb.ppc64-latest.args | 2 +- .../pseries-serial-usb.ppc64-latest.xml | 2 +- .../pseries-usb-default.ppc64-latest.args | 2 +- .../pseries-usb-default.ppc64-latest.xml | 2 +- .../pseries-usb-kbd.ppc64-latest.args | 2 +- .../pseries-usb-kbd.ppc64-latest.xml | 2 +- .../pseries-usb-multi.ppc64-latest.args | 2 +- .../pseries-usb-multi.ppc64-latest.xml | 2 +- ...series-vio-user-assigned.ppc64-latest.args | 7 +- ...pseries-vio-user-assigned.ppc64-latest.xml | 2 +- .../pseries-vio.ppc64-latest.args | 7 +- .../pseries-vio.ppc64-latest.xml | 2 +- ...fault-pseries.ppc64-latest.abi-update.args | 2 +- ...efault-pseries.ppc64-latest.abi-update.xml | 2 +- ...ntroller-default-pseries.ppc64-latest.args | 2 +- ...ontroller-default-pseries.ppc64-latest.xml | 2 +- ...fault-unavailable-pseries.ppc64-latest.xml | 2 +- tests/qemuxmlconftest.c | 8 +- tests/testutilshostcpus.h | 11 + tests/testutilsqemu.c | 4 + tests/testutilsqemu.h | 1 + 101 files changed, 41008 insertions(+), 103 deletions(-) create mode 100644 src/cpu_map/ppc64_POWER11.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.ppc64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} (100%) create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.args create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.err create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.xml create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.xml -- 2.48.1

6 22