June 2026 - Devel - libvirt List Archives

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 13 Aug '26

13 Aug '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

10 45

[PATCH v8 0/4] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 12 Aug '26

12 Aug '26

This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another. The 1st patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 2nd patch. The third patch introduces unit testing of the new nftables driver. Finally the last patch introduces a new element to the nwfilterbinding XML which is used to detect and run a cleanup on the old firewall rules defined via the previous used nwfilter firewall backend. - Implemented very basic nwfilter.conf reading, choosing a nwfilter driver based on the name of the drivers (nftables/ebiptables). Defaults to the nftables driver, based on the firewall_backend_priority meson option, following the bridge driver logic. - Implemented nft tracing and counters usable via nwfilter.conf options "enable_trace" and "enable_counters" - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603, benchmarks showed that the amount of iifname jumps for each interface in the root chains is the cause for this. Switched the nftables driver towards a vmap (verdict map) so we can have 1 rule that jumps to the correct root input/output chain per interface. Which improves throughput as when the number of interface check and jump rules increases the throughput decreases. The issue describes the interface matching works using the interface name and the majority of the effort is the strncpy, this patch also switches nftables to an interface_index compare instead. However, just using the interface_index is not enough, the amount of oif and iif jump rules causes quite the performance degradation, the vmap instead solves this. - Split rules into separate tables: "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet" to preserve existing firewall behavior. - Reworked chain logic for clarity with root -input/-output chains per interface. input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). - Stuck with prerouting and postrouting as hooks for input / output on the _ethernet and _inet table. This makes it easier to merge the tables in the future. Saving management of two tables and decreasing the amount of tables a packet sees. Currently ebtables filtering happens via PREROUTING and POSTROUTING hooks, while ip/ip6tables filtering happens in the output/forward hooks. - Stuck with 2 tables for compatibility reasons with eb iptables, unifying into 1 table will break users firewall definitions, which depend on being able to do accepts on ethernet rules (which currently get defined via ebtables) and additional filtering via the ip rules (which currently get defined via ip(6)tables). The nwfilter_nftables_driver keeps splitting the ethernet and inet rules in seperate tables "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet". - Rewrote chain logic, so it is easier to understand, input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). _ethernet and _inet table follow the same style and hook in the same way. - Simplified conntrack handling: rules with accept+conntrack are duplicated to the opposite chain for symmetric behavior, to support the existing ebiptables logic. - Firewall updates continue use tmp names for atomic replacement. Unsupported nwfilter features (for now): - IPSets (potential future support via nft sets) - Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions Future improvements: - Use `nft -f` for atomic rule application. - Optional single-table mode via nwfilter.conf. - Optimize boot phase with chain hash comparison. --- Changes in v8: - Fix incompatibility issue with ebiptables driver for inet rules Inet rules in nftables are now placed on the root chains following iptables logic inside the ebiptables driver. Introducing subchains for inet caused sorting problems, subchains can accept or drop a packet which on the ebiptables driver inet rules would have been filtered out by rules that were sorted differently. Changes in v7: - Add backend XML element to virnwfilterbinding, to support switching from nwfilter firewall backend Changes in v6: - Add STP support - Add GARP support - Remove comment "priority=%" leftover from debugging Changes in v5: - Fix rarp support via nft raw payload expression Changes in v4: - Fix rarp nft commands "arp saddr ether" "arp daddr ether" - Filter chain creation, don't create unnecessary chains - Apply danpb seperate argument suggestion - Fix table not existing errors in drop all rules - Fix table not existing errors in apply basic rules Changes in v3: - Renamed -other to -inet - Renamed - to _ in table names - Updated rule / chain sorting on ethernet table to to copy ebtables logic - Fix possible broken revert path - Fix remove rules not working in some cases, EBUSY - Shared functions camel case commit - Rename config option - Add extra config params, enable_trace, enable_counters This required passing the config struct to the ebip/nft nwfilter drivers - Add extra augeaus files Changes in v2: - Rename {ebip,nf}tables specific test files in 1 directory instead of seperating them in different directories. - Added default nwfilter.conf file in git, documented including augeas files - Replaced hardcoding of default driver based on existing firewall_backend_priority meson option. - Added nwfilter_driver_conf.{h,c} for configuration handling, to match the common pattern used in other drivers. Dion Bosschieter (4): nwfilter: add nwfilter nftables driver nwfilter: allow use of nftables nwfilter driver via nwfilter.conf nwfilter: add unit tests and test data for nwfilter nftables driver nwfilter: add used firewall backend to nwfilterbinding libvirt.spec.in | 7 + po/POTFILES | 2 + src/conf/schemas/nwfilterbinding.rng | 7 + src/conf/virnwfilterbindingdef.c | 17 +- src/conf/virnwfilterbindingdef.h | 1 + src/conf/virnwfilterobj.h | 20 - src/nwfilter/libvirtd_nwfilter.aug | 45 + src/nwfilter/meson.build | 38 + src/nwfilter/nwfilter.conf.in | 50 + src/nwfilter/nwfilter_driver.c | 67 +- src/nwfilter/nwfilter_driver_conf.c | 214 + src/nwfilter/nwfilter_driver_conf.h | 69 + src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/nwfilter/nwfilter_ebiptables_driver.h | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 144 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2864 +++++++++++++ src/nwfilter/nwfilter_nftables_driver.h | 28 + src/nwfilter/nwfilter_tech_driver.h | 3 +- src/nwfilter/test_libvirtd_nwfilter.aug.in | 7 + tests/meson.build | 2 + tests/nwfilternftablestest.c | 426 ++ .../ah-ipv6-linux.nftables.args | 298 ++ .../ah-linux.nftables.args | 292 ++ .../all-ipv6-linux.nftables.args | 280 ++ .../all-linux.nftables.args | 274 ++ .../arp-linux.nftables.args | 285 ++ .../comment-linux.nftables.args | 502 +++ .../conntrack-linux.nftables.args | 190 + .../esp-ipv6-linux.nftables.args | 298 ++ .../esp-linux.nftables.args | 292 ++ .../example-1-linux.nftables.args | 252 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 368 ++ .../icmp-direction-linux.nftables.args | 226 ++ .../icmp-direction2-linux.nftables.args | 226 ++ .../icmp-direction3-linux.nftables.args | 176 + .../icmp-linux.nftables.args | 248 ++ .../icmpv6-linux.nftables.args | 316 ++ .../igmp-linux.nftables.args | 292 ++ .../ip-linux.nftables.args | 199 + .../ipt-no-macspoof-linux.nftables.args | 166 + .../ipv6-linux.nftables.args | 481 +++ .../iter1-linux.nftables.args | 292 ++ .../iter2-linux.nftables.args | 3532 +++++++++++++++++ .../iter3-linux.nftables.args | 410 ++ .../mac-linux.nftables.args | 176 + .../rarp-linux.nftables.args | 207 + .../sctp-ipv6-linux.nftables.args | 316 ++ .../sctp-linux.nftables.args | 316 ++ .../stp-linux.nftables.args | 233 ++ .../target-linux.nftables.args | 454 +++ .../target2-linux.nftables.args | 302 ++ .../tcp-ipv6-linux.nftables.args | 316 ++ .../tcp-linux.nftables.args | 452 +++ .../udp-ipv6-linux.nftables.args | 316 ++ .../udp-linux.nftables.args | 316 ++ .../udplite-ipv6-linux.nftables.args | 298 ++ .../udplite-linux.nftables.args | 292 ++ .../vlan-linux.nftables.args | 257 ++ tests/nwfilterxml2nftfirewalltest.c | 432 ++ .../filter-vars.xml | 1 + .../simple-backend.xml | 10 + tests/virnwfilterbindingxml2xmltest.c | 1 + 64 files changed, 18845 insertions(+), 119 deletions(-) create mode 100644 src/nwfilter/libvirtd_nwfilter.aug create mode 100644 src/nwfilter/nwfilter.conf.in create mode 100644 src/nwfilter/nwfilter_driver_conf.c create mode 100644 src/nwfilter/nwfilter_driver_conf.h create mode 100644 src/nwfilter/nwfilter_nftables_driver.c create mode 100644 src/nwfilter/nwfilter_nftables_driver.h create mode 100644 src/nwfilter/test_libvirtd_nwfilter.aug.in create mode 100644 tests/nwfilternftablestest.c create mode 100755 tests/nwfilterxml2firewalldata/ah-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ah-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/arp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/comment-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/conntrack-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/hex-data-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmpv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/igmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ip-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipt-no-macspoof-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/mac-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/rarp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-linux.nftables.args create mode 100644 tests/nwfilterxml2firewalldata/stp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/vlan-linux.nftables.args create mode 100644 tests/nwfilterxml2nftfirewalltest.c create mode 100644 tests/virnwfilterbindingxml2xmldata/simple-backend.xml -- 2.43.0

3 9

[PATCH 0/2] Properly handle tri-state for KVM options
by Chris Riches 03 Aug '26

03 Aug '26

Two of the qemu kvm_features (kvm-poll-control and kvm-pv-ipi) were only emitted when on or when off respectively, rather than handling the full tri-state for each (on, off, absent). This meant that config like <poll-control state='off'/> was a no-op, equivalent to not specifying poll-control at all, which fails to prevent QEMU from enabling it based on its own internal defaults. In particular, this meant that having both <cpu mode='host-passthrough'> and <poll-control state='off'/> would cause the latter to be ignored, since libvirt would emit no explicit kvm-poll-control arg, and QEMU defaults to enabling most KVM features when CPU passthrough is enabled. Fix these two cases such that explicit on/off are both respected. The `hidden` and `hint-dedicated` options are left as-is, since these really do only make sense in the `on` direction; QEMU will never automatically enable them. Chris Riches (2): qemu: Emit explicit kvm-poll-control=off when disabled qemu: Emit explicit kvm-pv-ipi=on when enabled src/qemu/qemu_command.c | 14 ++++++++++---- .../kvm-features-off.x86_64-latest.args | 2 +- .../kvm-features.x86_64-latest.args | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) -- 2.43.0

2 7

[PATCH v2 0/6] Add TLS-PSK support for migration
by Abhisek Panda 29 Jul '26

29 Jul '26

QEMU provides the capability to encrypt the migration data stream using two transport layer security (TLS) authentication schemes: X.509 certificates and pre-shared keys (PSK). Currently, Libvirt only supports the X.509-based TLS authentication scheme. In TLS X.509 certificates, a set of live migrations utilize a fixed set of static certificates for encrypted migration. In this authentication scheme, users require to deploy a certificate authority and monitor the certificate expiration window. In case certificates are compromised all the future live migrations are vulnerable. To resolve this, this patch series introduce the support for pre-shared key-based authentication scheme. This mechanism relies on symmetric pre-shared keys (a secret key that is known to both sender and receiver prior to secure communication) for providing secure transfer of data. Libvirt solely manages the lifecycle of the ephemeral pre-shared keys, including, generation, persistent storage, and cleanup. Libvirt generates the key on the source machine, then transfers it to the destination machine using the migration cookie. To allow users to configure the size of the key, Libvirt provides the migrate_tls_psk_length configuration parameter in qemu.conf. To avoid introduction of an additional VIR_MIGRATE_* flag, we rely on existing the VIR_MIGRATE_TLS flag. If the VIR_MIGRATE_TLS flag is set but the ca-cert.pem file is missing on the source, then we fallback to using PSK-based authentication scheme during migration. v2: 1. Libvirt manages the lifecycle of pre-shared keys. 2. Transfer of keys to the destination via the migration cookie 3. Remove the VIR_MIGRATE_TLS_PSK flag instead rely on VIR_MIGRATE_TLS and availability of ca-cert.pem on source. 4. Drop VIR_MIGRATE_PARAM_TLS_PSK_DIRECTORY, Libvirt solely manages the pre-shared keys. Abhisek Panda (6): conf: Add a configuration param for TLS-PSK qemu: Manage a pre-shared key's lifecycle qemu: Add support to build the tls-creds-psk object qemu: rename tls-creds-x509 obj related functions qemu: Manage tls-creds-psk object lifecycle qemu: Set up the migrate TLS-PSK objects include/libvirt/libvirt-domain.h | 13 +- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 8 ++ src/qemu/qemu_alias.c | 19 ++- src/qemu/qemu_alias.h | 5 +- src/qemu/qemu_backup.c | 2 +- src/qemu/qemu_command.c | 28 +++- src/qemu/qemu_command.h | 7 + src/qemu/qemu_conf.c | 10 ++ src/qemu/qemu_conf.h | 1 + src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_hotplug.c | 124 +++++++++++----- src/qemu/qemu_hotplug.h | 42 ++++-- src/qemu/qemu_migration.c | 135 ++++++++++++++---- src/qemu/qemu_migration_cookie.c | 125 ++++++++++++++++ src/qemu/qemu_migration_cookie.h | 5 + src/qemu/qemu_migration_params.c | 109 ++++++++++---- src/qemu/qemu_migration_params.h | 22 ++- src/qemu/qemu_postparse.c | 2 +- src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/qemumigparamsdata/tls-enabled.json | 2 +- tests/qemumigparamsdata/tls-enabled.reply | 2 +- tests/qemumigparamsdata/tls-enabled.xml | 2 +- tests/qemumigparamsdata/tls-hostname.json | 2 +- tests/qemumigparamsdata/tls-hostname.reply | 2 +- tests/qemumigparamsdata/tls-hostname.xml | 2 +- tests/qemumigrationcookiexmltest.c | 12 +- tests/qemumonitorjsontest.c | 4 +- tests/qemustatusxml2xmldata/upgrade-out.xml | 2 +- .../chardev-backends-json.x86_64-9.1.0.args | 8 +- .../chardev-backends-json.x86_64-latest.args | 8 +- .../chardev-backends.x86_64-9.1.0.args | 8 +- .../chardev-backends.x86_64-latest.args | 8 +- ...rk-tlsx509-nbd-hostname.x86_64-latest.args | 6 +- ...isk-network-tlsx509-nbd.x86_64-latest.args | 6 +- ...-tlsx509-chardev-verify.x86_64-latest.args | 4 +- ...ial-tcp-tlsx509-chardev.x86_64-latest.args | 4 +- ...-tlsx509-secret-chardev.x86_64-latest.args | 4 +- 38 files changed, 576 insertions(+), 171 deletions(-) -- 2.43.7

2 19

[RFC] sanlock: Add option to check ownership of disk leases
by Jim Fehlig 18 Jul '26

18 Jul '26

From: Jim Fehlig <jfehlig(a)suse.com> In a clustered environment it may be desirable to provision disk leases for use by a specific domain. This patch adds a 'check_disk_lease_owner' option to the sanlock driver to check that leases are owned by the domain attempting to acquire them. sanlock's Lock Value Block (LVB) is used to store the owning domain UUID within the lease. When a domain is started and attempts to acquire its leases, the sanlock driver will ensure its UUID matches the UUID recorded in the leases. Any mismatches will cause lease acquisition and domain startup to fail. The 'check_disk_lease_owner' option is disabled by default. When enabled, it can be used with auto_disk_leases or leases managed by an external application. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- Inspired by Claudio, implemented by Jim :-) src/locking/libvirt_sanlock.aug | 1 + src/locking/lock_driver_sanlock.c | 78 ++++++++++++++++++++++++- src/locking/sanlock.conf | 23 ++++++++ src/locking/test_libvirt_sanlock.aug.in | 1 + 4 files changed, 102 insertions(+), 1 deletion(-) diff --git a/src/locking/libvirt_sanlock.aug b/src/locking/libvirt_sanlock.aug index 62d0672952..af6c25755f 100644 --- a/src/locking/libvirt_sanlock.aug +++ b/src/locking/libvirt_sanlock.aug @@ -25,6 +25,7 @@ module Libvirt_sanlock = | int_entry "io_timeout" | str_entry "user" | str_entry "group" + | bool_entry "check_disk_lease_owner" let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ] let empty = [ label "#empty" . eol ] diff --git a/src/locking/lock_driver_sanlock.c b/src/locking/lock_driver_sanlock.c index a07f3652c1..7ed1081cbd 100644 --- a/src/locking/lock_driver_sanlock.c +++ b/src/locking/lock_driver_sanlock.c @@ -67,6 +67,7 @@ struct _virLockManagerSanlockDriver { unsigned int hostID; bool autoDiskLease; char *autoDiskLeasePath; + bool checkDiskLeaseOwner; unsigned int io_timeout; /* under which permissions does sanlock run */ @@ -147,6 +148,10 @@ virLockManagerSanlockLoadConfig(virLockManagerSanlockDriver *driver, if (virConfGetValueBool(conf, "require_lease_for_disks", &driver->requireLeaseForDisks) < 0) return -1; + if (virConfGetValueBool(conf, "check_disk_lease_owner", + &driver->checkDiskLeaseOwner) < 0) + return -1; + if (virConfGetValueUInt(conf, "io_timeout", &driver->io_timeout) < 0) return -1; @@ -839,6 +844,73 @@ virLockManagerSanlockRegisterKillscript(int sock, return 0; } +static int virLockManagerSanlockCheckOwner(virLockManagerSanlockDriver *driver, + virLockManagerSanlockPrivate *priv) +{ + char lvb[VIR_UUID_STRING_BUFLEN] = {0}; + char vm_uuidstr[VIR_UUID_STRING_BUFLEN]; + int rv; + size_t i; + + if (!driver->checkDiskLeaseOwner) + return 0; + + virUUIDFormat(priv->vm_uuid, vm_uuidstr); + + for (i = 0; i < priv->res_count; i++) { + memset(lvb, 0, sizeof(lvb)); + + rv = sanlock_get_lvb(0, priv->res_args[i], lvb, sizeof(lvb)); + if (rv < 0) { + /* Failed to read LVB, treat as "legacy" lease + * without ownership tracking and skip the check. + */ + VIR_DEBUG("Failed to read LVB, skipping ownership check"); + continue; + } + + if (lvb[0] == '\0') { + VIR_DEBUG("Writing VM UUID to empty LVB"); + /* Empty LVB: this lease does not yet have an owner recorded. Write + * the domain's UUID so that subsequent acquire attempts by other + * domains will be rejected. This handles the auto_disk_leases case + * where lease files are created by libvirt. rather + */ + if ((rv = sanlock_set_lvb(0, priv->res_args[i], vm_uuidstr, + sizeof(vm_uuidstr))) < 0) { + char *err = NULL; + if (virLockManagerSanlockError(rv, &err)) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to set LVB for lease %1$s: %2$s"), + priv->res_args[i]->disks[0].path, NULLSTR(err)); + VIR_FREE(err); + } else { + virReportSystemError(-rv, + _("Failed to set LVB for lease %1$s"), + priv->res_args[i]->disks[0].path); + } + return -1; + } + continue; + } + + VIR_DEBUG("Comparing LVB UUID '%s' to VM UUID '%s'", lvb, vm_uuidstr); + if (STRNEQ(lvb, vm_uuidstr)) { + /* + * LVB contains a different domain UUID. This lease + * was provisioned for another domain and must not + * be acquired by this one. + */ + virReportError(VIR_ERR_RESOURCE_BUSY, + _("Disk lease %1$s is already assigned to domain %2$s, not %3$s"), + priv->res_args[i]->disks[0].path, lvb, vm_uuidstr); + return -1; + } + } + return 0; +} + + static int virLockManagerSanlockAcquire(virLockManager *lock, const char *state, unsigned int flags, @@ -934,7 +1006,8 @@ static int virLockManagerSanlockAcquire(virLockManager *lock, if (!(flags & VIR_LOCK_MANAGER_ACQUIRE_REGISTER_ONLY)) { VIR_DEBUG("Acquiring object %u", priv->res_count); - if ((rv = sanlock_acquire(sock, priv->vm_pid, 0, + if ((rv = sanlock_acquire(sock, priv->vm_pid, + driver->checkDiskLeaseOwner ? SANLK_ACQUIRE_LVB : 0, priv->res_count, priv->res_args, opt)) < 0) { char *err = NULL; @@ -949,6 +1022,9 @@ static int virLockManagerSanlockAcquire(virLockManager *lock, } goto error; } + + if (virLockManagerSanlockCheckOwner(driver, priv) < 0) + goto error; } VIR_FREE(opt); diff --git a/src/locking/sanlock.conf b/src/locking/sanlock.conf index 3c356bef9c..e7d6938e84 100644 --- a/src/locking/sanlock.conf +++ b/src/locking/sanlock.conf @@ -67,3 +67,26 @@ # access them. Accepted values are described in qemu.conf. #user = "root" #group = "root" + +# +# Flag to enable verifying if disk leases have been provisioned +# for domains attempting to acquire them. This is accomplished +# using sanlock's Lock Value Block (LVB), a 512 byte application +# specific block in the lease lockspace where the domain's UUID +# can be stored when the lease is created. When libvirt starts a +# domain, the sanlock driver will check for a valid and matching +# UUID in the LVB of all leases. This prevents a lease that was +# provisioned for one domain from accidentally being used by a +# different domain. +# +# When enabled, if a lease file has an empty LVB, the UUID of the +# acquiring domain is written into the LVB automatically, so that +# subsequent lease acquisition attempts by other domains will be +# rejected. This behavior accommodates the auto_disk_leases case, +# where leases are created by libvirt. If leases are managed by +# an external application, it must write the domain UUID into the +# LVB during lease creation. +# +# Defaults to disabled. +# +#check_disk_lease_owner = 0 diff --git a/src/locking/test_libvirt_sanlock.aug.in b/src/locking/test_libvirt_sanlock.aug.in index 5eabb6726d..e468a2cdcd 100644 --- a/src/locking/test_libvirt_sanlock.aug.in +++ b/src/locking/test_libvirt_sanlock.aug.in @@ -9,3 +9,4 @@ module Test_libvirt_sanlock = { "io_timeout" = "0" } { "user" = "root" } { "group" = "root" } +{ "check_disk_lease_owner" = "0" } -- 2.51.0

2 4

Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases
by Daniel P. Berrangé 10 Jul '26

10 Jul '26

QEMU has implemented four generic USB controllers * UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller We have two variants of XHCI, the generic one (hcd-xhci.c) and the NEC one (hcd-xhci-nec.c) Historically for security reports we have considered all of them in scope of virtualization, since initially with KVM the XHCI impl was not present in QEMU & thus KVM guests used UHCI/EHCI with USB tablet for a period of time All of the USB subsystem is currently orphaned, so we have no dedicated maintainer available to deal with bug reports (volunteers welcome to step up here...) While the need for USB is reduced given the availability of virtio-input, not all guests have drivers out of the box, so at least USB tablet is still interesting for KVM use cases with some modern OS. It is also not that unusual for people to need USB host device assignment with KVM virt to make various pieces of specialized hardware (security tokens, smart cards, custom dongles, etc) available directly to guests. IOW, we can't entirely exclude USB from virtualization use cases IMHO. In terms of virtualization, XHCI is the only impl that is sensible to use. UHCI/OHCI/EHCI all impose an unreasonable CPU load on any guest usage of USB. XHCI should be supported by any guest OS approx the last 15 years, which should be sufficient for virtualization use cases with OS that are not EOL by their vendor. Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab: https://www.qemu.org/docs/master/system/security.html#non-virtualization-us… The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment: https://www.qemu.org/docs/master/system/security.html#virtualization-use-ca… The other NEC XHCI variant (hcd-xhci-nec.c) would also be treated as non-virtualization use case, since it needlessly duplicates hcd-xhci.c impl and thus is only interesting for emulation of this specific HW variant. NB, there are no functional limitations / restrictions from this policy, it is largely just a semantic exercise. From a management application POV, however, it would strongly suggest that guests be configured with XHCI as the default choice if the user asks for USB, and in turn also imply that '-usb' not be used since that is UHCI/OHCI typically. CC'ing libvirt, though it is really a matter for virt-install/virt-manager/ openstack/kubevirt etc above libvirt to pick their defaults for USB controllers. None the less XHCI would still be in search of a maintainer to step forward and handle ongoing development and maint work. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

5 7

[RFC PATCH 0/3] Arm CPU features with supported values
by sandesh.patel＠nutanix.com 07 Jul '26

07 Jul '26

From: Sandesh Patel <sandesh.patel(a)nutanix.com> Hi, This RFC series adds libvirt support for ARM CPU features that are exposed by QEMU as multi-valued properties, rather than the on/off booleans we are used to from x86. Background ========== On ARM, several CPU properties can take one of a small set of values (e.g. "0.0", "1.0", "1.1_base", "off"), and the set of values supported by each property is host-specific. This cannot be expressed using libvirt's existing boolean feature model. This series depends on a pending QEMU RFC [1] that introduces non-boolean feature handling for ARM CPUs. That series also adds a new QMP command, query-arm-cpu-props-info, which reports the values the host accelerator supports for each ARM CPU property. Example reply fragment: { "name": "hw_prop_WRPs", "supported-values": ["0-3"], "type": "number" } On top of that QEMU work, this libvirt RFC wires up the end-to-end flow: probing the host, caching the probed information, exposing the values in the guest CPU XML, and passing them through to the QEMU -cpu command line. I am posting this as an RFC primarily to get maintainer feedback on the overall approach before investing in the missing pieces (in particular, value validation, which is intentionally not yet implemented). See "Open questions" below. Overview of the series ====================== 1. "Query supported ARM CPU property values from QEMU" Adds the QMP wrapper for query-arm-cpu-props-info, a new QEMU_CAPS_QUERY_ARM_CPU_PROPS_INFO capability bit, and the qemuMonitorCPUPropsInfoList data structure. The command is issued on ARM + KVM hosts and the reply is stored in the per-accelerator capabilities. 2. "Cache ARM CPU property information" Persists the probed list into the on-disk QEMU capabilities cache as <cpuPropertyInfo>, so that subsequent libvirtd restarts do not need to re-issue the QMP query. 3. "Support 'value' attribute on CPU features" Extends the guest CPU XML with an optional 'value' attribute on <feature>: <cpu mode='host-passthrough'> <feature policy='require' name='feat_RAS' value='1.0'/> <feature policy='require' name='hw_prop_API' value='off'/> <feature policy='enable' name='hw_prop_WRPs' value='2'/> </cpu> When a feature carries a non-NULL 'value', libvirt emits '<name>=<value>' on the QEMU -cpu command line; in that case the policy must be 'require' or 'force'. The existing policy-driven '=on' / '=off' path is used only for features without an explicit value. All ARM property names returned by query-arm-cpu-props-info are registered in src/cpu_map/arm_features.xml so that the guest XML parser and validator accept them. With this change, the generated QEMU command line can look like: -cpu host-passthrough,hw_prop_API=off,hw_prop_WRPs=2 Open questions ============== - Value validation: should libvirt validate the requested value against the host's supported-values list at define time, at start time, or defer entirely to QEMU? - Policy vs. value conflicts: is requiring policy='require' / 'force' whenever 'value' is set the right rule? - Caching location: is the per-accelerator QEMU capabilities cache the right place to store the probed property list, or should this live alongside the CPU model data in cpu_map? [1] https://lore.kernel.org/qemu-arm/20260605083358.1320563-1-khushit.shah@nuta… Thanks Sandesh Patel (3): Query supported ARM CPU property values from QEMU Cache ARM CPU property information Support 'value' attribute on CPU features src/conf/cpu_conf.c | 21 ++- src/conf/cpu_conf.h | 1 + src/conf/schemas/cputypes.rng | 5 + src/cpu_map/arm_features.xml | 170 ++++++++++++++++++ src/qemu/qemu_capabilities.c | 133 +++++++++++++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 ++ src/qemu/qemu_monitor.c | 51 ++++++ src/qemu/qemu_monitor.h | 26 +++ src/qemu/qemu_monitor_json.c | 66 +++++++ src/qemu/qemu_monitor_json.h | 5 + .../caps_11.1.0_aarch64.replies | 69 +++++++ .../caps_11.1.0_aarch64.xml | 14 ++ tests/qemumonitorjsontest.c | 91 ++++++++++ ...arch64-cpu-passthrough.aarch64-latest.args | 2 +- ...aarch64-cpu-passthrough.aarch64-latest.xml | 6 +- .../aarch64-cpu-passthrough.xml | 6 +- tests/testutilshostcpus.h | 74 ++++---- 18 files changed, 709 insertions(+), 45 deletions(-) -- 2.43.7

3 5

[PATCH v3] lxc: Assign aliases to filesystem and network devices
by rsmigiel＠redhat.com 07 Jul '26

07 Jul '26

This patch addresses the missing device alias assignment for filesystem and network interface devices in LXC domains. Before this patch, virsh dumpxml showed filesystem and network devices without aliases: <filesystem type='mount' accessmode='passthrough'> <source dir='/shared6'/> <target dir='/shared6'/> </filesystem> <interface type='bridge'> <mac address='b8:3f:d2:c9:e8:bd'/> <source bridge='br0'/> <target dev='vnet8'/> <model type='virtio'/> </interface> After this patch, filesystem devices have auto-generated aliases: <filesystem type='mount' accessmode='passthrough'> <source dir='/shared6'/> <target dir='/shared6'/> <alias name='fs1'/>  </filesystem> <interface type='bridge'> <mac address='b8:3f:d2:c9:e8:bd'/> <source bridge='br0'/> <target dev='vnet8'/> <model type='virtio'/> <alias name='net4'/>  </interface> Changes in v3: - Implemented new index allocation algorithm, scans existing aliases before new index allocation - Added hotplug support in lxcDomainAttachDeviceNetLive() - Handles gaps in numbering after device detach/attach - Follows QEMU's qemuAssignDeviceNetAlias() pattern - Tested hotplug scenario The implementation follows the same pattern used by QEMU's qemuAssignDeviceNetAlias() and qemuAssignDeviceFSAlias(). This is needed as a prerequisite for fixing bug #63 (loop device path length limitation), where device aliases will be used to compose synthetic lo_file_name references in the format "libvirt-$UUID-$DEVALIAS".

3 4

[PATCH v5 00/35] monitor: turn QMP and HMP into QOM objects
by Daniel P. Berrangé 03 Jul '26

03 Jul '26

Conceptually -object and object_add/object_del should be sufficient for essentially all QEMU configuration....if only we ported all our internal custom backends/devices/etc to QOM. That is of course a big job which is why it hasn't happened. This series started with the premise that the monitor is one of the easier areas to convert since we have no more than three classes, a common base, and QMP and HMP subclasses[1]. So why not give it a go and thus unlock the ability to dynamically create/delete monitors in QMP/HMP. This series does the conversion in a great many small steps to better understand the implications at each stage. The high level outcome of this series is * HMP and QMP monitors are QOM objects, 'monitor-hmp' and 'monitor-qmp' respectively * Both can be cold plugged and hot plugged. QMP only, can also be hot unplugged. * '-mon' is obsolete, deprecated and replaced by '-object', but -monitor, -qmp and kept as high level syntax sugar * QMP gains a concept of "close-action" which makes it possible to mark a monitor for auto-delete. The monitor hot-unplug code and the qtest and functional testing code is heavily derived from a series sent by Christian Brauner which proposed new monitor_add/monitor_del commands: https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html I left Christian's authorship & SoB on the patches which were derived from his code, though the code has been refactored quite a bit in places, so bugs are quite possibly my own. Note that Christian's series allowed the use of "monitor_del" commands against the current monitor session. ie a client could delete the very monitor it was using. This is an awkward concept as it needs special casing to delay the deletion to happen in the background, such that that the QMP response to 'monitor_del' could still be sent back. This also left the chardev was orphaned as there's no way to run 'chardev_dev' in that usage pattern. To provide an alternative mechanism to address the same use case, this series introduces the 'close-action' concept mentioned above, that allows hotplugging a monitor to service a specific task, with the monitor being purged when the script closes its connection. This avoids the special casing that an explicit "self deletion" paradigm required. While supporting hotplug of HMP was trivial, I didn't do any work to think about hotunplug of HMP, since IMHO it is of limited value given HMP's typical use cases. [1] ~~~ we did all this not because it was easy, but because we thought it would be easy ~~~ Changed in v5: - Address another race when looking up monitor by ID - Refer to "line editting" when talking about HMP readline feature - Misc typos - Fix mis-placed setting of 'delete_pending' - Add test case to validate reconnecting to QMP Changed in v4: - Hold reference into BH to avoid race with auto-delete Changed in v3: - Removed unused 'dead' struct field - Make use of 'setup_pending' struct field across BH - Add missing free of chardev_id - Add missnig ERRP_GUARD in monitor_new_qmp - Misc docs typos / rephrasing - Moved docs patch to the end - Fixed docs about the default QOM ID naming for legacy monitor syntax - Fixed random sleep time calculation in tests Christian Brauner (6): monitor: convert from oneshot BH to persistent BH monitor: reject attempts to delete the current monitor monitor: protect qemu_chr_fe_accept_input with monitor lock monitor: implement support for deleting QMP objects tests/qtest: add tests for dynamic monitor add/remove tests/functional: add e2e test for dynamic QMP monitor hotplug Daniel P. Berrangé (29): qom: replace 'can_be_deleted' with 'prepare_delete' monitor: replace 'common' with 'parent_obj' in MonitorHMP monitor: replace 'common' with 'parent_obj' in MonitorQMP monitor: rename monitor_init* to monitor_new* monitor: minimal conversion of monitors to QOM monitor: add 'chardev' property to Monitor base class monitor: add 'readline' property to HMP Monitor class monitor: add 'pretty' property to QMP Monitor class monitor: remove 'skip_flush' field monitor: move monitor_data_(init|destroy) into QOM init/finalize monitor: use class methods for monitor_vprintf monitor: use class methods for monitor_qapi_event_emit monitor: use class methods for monitor_accept_input monitor: use class method for I/O thread request monitor: use dynamic cast in monitor_qmp_requests_pop_any_with_lock util: use dynamic cast in error vreport monitor: drop unused monitor_cur_is_qmp monitor: use dynamic cast in QMP commands monitor: use dynamic cast in monitor_is_hmp_non_interactive monitor: drop unused monitor_is_qmp method monitor: eliminate monitor_is_hmp_non_interactive method monitor: implement "user creatable" interface for adding monitors tests/functional: add a stress test for monitor hot unplug qom: add method for getting the "id" of a QOM object qom: add trace events for user creatable create/delete APIs monitor: add support for auto-deleting monitors upon close tests: switch from -mon to -object monitor-qmp qemu-options: document new monitor-hmp and monitor-qmp objects docs: mark '-mon' as deprecated in favour of -object MAINTAINERS | 1 + backends/cryptodev.c | 10 +- backends/hostmem.c | 5 +- backends/iommufd.c | 10 +- block/throttle-groups.c | 10 +- chardev/char.c | 3 +- docs/about/deprecated.rst | 10 + docs/devel/writing-monitor-commands.rst | 4 +- docs/system/arm/xenpvh.rst | 4 +- docs/system/i386/xen.rst | 3 +- docs/system/i386/xenpvh.rst | 4 +- event-loop-base.c | 8 +- gdbstub/system.c | 4 +- include/monitor/monitor.h | 23 +- include/qom/object.h | 10 + include/qom/object_interfaces.h | 26 +- include/system/event-loop-base.h | 2 +- migration/migration-hmp-cmds.c | 5 +- monitor/hmp-cmds.c | 7 +- monitor/hmp.c | 181 ++++++++-- monitor/monitor-internal.h | 73 ++-- monitor/monitor.c | 262 +++++++------- monitor/qmp-cmds-control.c | 12 +- monitor/qmp-cmds.c | 14 +- monitor/qmp.c | 319 +++++++++++++++--- net/can/can_core.c | 5 +- python/qemu/machine/machine.py | 4 +- qapi/qom.json | 62 ++++ qemu-options.hx | 56 ++- qom/object.c | 17 + qom/object_interfaces.c | 20 +- qom/trace-events | 5 + storage-daemon/qemu-storage-daemon.c | 2 +- stubs/monitor-core.c | 5 - stubs/monitor-internal.c | 3 +- system/vl.c | 12 +- tests/functional/generic/meson.build | 1 + .../generic/test_monitor_hotplug.py | 305 +++++++++++++++++ tests/qemu-iotests/245 | 4 +- tests/qtest/libqtest.c | 2 +- tests/qtest/qmp-test.c | 174 ++++++++++ tests/unit/test-util-sockets.c | 1 - tools/qemu-vnc/stubs.c | 5 - ui/ui-hmp-cmds.c | 2 +- util/error-report.c | 13 +- util/main-loop.c | 5 +- 46 files changed, 1386 insertions(+), 327 deletions(-) create mode 100755 tests/functional/generic/test_monitor_hotplug.py -- 2.54.0

4 70

[PATCH v4 0/8] powerpc: Testcase improvements and Power8E/NVL removal
by Aditya Gupta 03 Jul '26

03 Jul '26

Overview ======== This patch series merged two patch series sent earlier: "Testcase improvements for PowerNV" "Remove deprecated Power8E and 8NVL CPUs" since the Power8E removal series depended on the former due to pnv-spi test Broadly contains 3 changes: 1. Testcase improvements: Add a testcase to detect regression in remote interrupts when XIVE changes, since such regression had occurred during Power11 XIVE changes: https://lore.kernel.org/qemu-devel/baf6c854-832b-4a2e-922f-d34e6dadf821@red… Also add Power11 chip and testcase in qtests, and fadump functional test 2. Power8E/Power8NVL removal Power8E and Power8NVL were deprecated since QEMU 10.1, with commit 264a604e7163 ("target/ppc: Deprecate Power8E and Power8NVL") Hence, remove usage (chip and core types) of Power8E and 8NVL from PowerNV, PSeries as well as testcases. 3. Maintainer changes Add myself as maintainer for PowerNV machine Testing ======= * Git tree for testing: https://gitlab.com/adi-g15-ibm/qemu/tree/feat_maintainer-v4 * Gitlab pipeline: https://gitlab.com/adi-g15-ibm/qemu/-/pipelines/2641510943 * Successful ppc64 functional tests, qtests, boot tests, builds at all commits Changelog ========= v4: + #1: added cores=1, as suggested by cedric, no functional change + #3: remove unneeded headers, as suggested by cedric + #3: keep power10 xive2 test, as suggested by nikhil v3: + #3: use machine_type array in pnv_xscom_addr, as suggested by shivang, harsh and balaton v2: + #1: put e1000e on socket 1, and disable it's cpu, as suggested by cedric + #1: pull out command fail checks into a helper, as suggested by shivang + #2: use g_autofree, suggested by cedric + #3: use g_autofree in tests updated + #8: remove G:, as suggested by daniel + rebased to upstream from previous split series: + #1: added checks to see if network is up and interrupts happened, based on shivang's review + #3: replaced common if-else-if check for machine type with pnv_get_machine_type + #7: added doc in removed-features, as suggested by cedric + #6,7: added rb from philippe + #8: new patch, maintainer change Aditya Gupta (8): tests/functional: Add remote interrupts test for PowerNV tests/qtest/pnv_spi: Test Power11 PNV_SPI tests/qtest: Add Power11 chip & machine to qtests tests/functional: Use default powernv machine instead of power10 ppc/pnv: Replace Power8E with Power11 for 'none' machine test ppc/pnv: Remove Power8E and Power8NVL pnv chips ppc/pnv: Remove Power8E and Power8NVL CPUs MAINTAINERS: Add self as maintainer for PowerNV MAINTAINERS | 2 +- docs/about/deprecated.rst | 9 --- docs/about/removed-features.rst | 8 +++ docs/system/ppc/powernv.rst | 2 +- docs/system/ppc/pseries.rst | 2 +- hw/ppc/pnv.c | 62 ----------------- hw/ppc/pnv_core.c | 2 - hw/ppc/spapr_cpu_core.c | 2 - include/hw/ppc/pnv.h | 8 --- target/ppc/cpu-models.c | 6 -- target/ppc/cpu-models.h | 4 -- target/ppc/cpu_init.c | 6 -- target/ppc/kvm.c | 4 +- tests/functional/ppc64/test_fadump.py | 2 +- tests/functional/ppc64/test_powernv.py | 95 ++++++++++++++++++++++++++ tests/qtest/machine-none-test.c | 2 +- tests/qtest/pnv-host-i2c-test.c | 10 ++- tests/qtest/pnv-spi-seeprom-test.c | 20 ++++-- tests/qtest/pnv-xive2-test.c | 21 ++++-- tests/qtest/pnv-xscom-test.c | 22 ++---- tests/qtest/pnv-xscom.h | 38 +++++++---- 21 files changed, 175 insertions(+), 152 deletions(-) base-commit: 30e8a06b64aa58a3990ba39cb5d09531e7d265e0 -- 2.54.0

3 11