May 2024 - Devel - libvirt List Archives

[RFC PATCH 0/1] support deprecated-props from query-cpu-model-expansion
by Collin Walling 19 Jun '24

19 Jun '24

Overview ======== QEMU will soon support reporting an optional array of deprecated features for an expanded CPU model via the query-cpu-model-expansion command. The intended use of this data is to make it easier for a user to define a CPU model with features flagged as deprecated set to disabled, thus rendering the guest migratable to future hardware that will out-right drop support for said features. Attached to this cover letter is only half of the bigger picture. I've updated the CPU model expansion ABI to parse the new array (if it's available) and store the result in a string list within the qemuMonitorCPUModelInfo struct. I also propose an approach on how to store/retrieve the list of deprecated features in the qemuCaps cache file. All feedback on this patch is certainly welcome. Please note: I do not provide any updates to the respective qemuCaps tests right now. The main goal of this post is to discuss the other half of the design: reporting and enabling a CPU model with deprecated features disabled. I believe the ideal solution involves a way for the user to easily configure their guest with this new data. Two ideas I currently have are outlined below. Other approaches are encouraged. Notes ===== - In my example below, I am running on a z14.2 machine. - The features that are flagged as deprecated for this model are: bpb, csske, cte, te. - The discussion regarding the QEMU changes can be found here: https://mail.gnu.org/archive/html/qemu-devel/2024-04/msg04605.html Example of Desired Changes ========================== Here is what I'd like the resulting guest's transient XML to look like for the <cpu> section (I have trimmed the features list for brevity): ... <cpu mode='custom' match='exact' check='partial'> <model fallback='forbid'>z14.2-base</model> <feature policy='require' name='aen'/> <feature policy='require' name='cmmnt'/> <feature policy='require' name='aefsi'/> ... <feature policy='disable' name='cte'/> *** <feature policy='require' name='ais'/> <feature policy='disable' name='bpb'/> *** <feature policy='require' name='ctop'/> <feature policy='require' name='gs'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> <feature policy='disable' name='te'/> *** <feature policy='require' name='cmm'/> <feature policy='disable' name='csske'/> *** </cpu> ... Ideas ===== New Host CPU Model ------------------ Create a new CPU model that is a mirror of the host CPU model with deprecated features turned off. Let's call this model "host-recommended". A user may define this model in the guest XML as they would any other CPU model: <cpu mode='host-recommended' check='partial'/> Just as how host-model works, anything defined nested in the <cpu> tag will be ignored. This model could potentially be listed in the domcapabilities output after the host-model: <cpu> <mode name='host-passthrough' supported='yes'> ... </mode> ... <mode name='host-model' supported='yes'> ... </mode> <mode name='host-recommended' supported='yes'> ... <feature policy='disable' name='cte'/> <feature policy='require' name='ais'/> <feature policy='disable' name='bpb'/> <feature policy='require' name='ctop'/> <feature policy='require' name='gs'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> <feature policy='disable' name='te'/> <feature policy='require' name='cmm'/> <feature policy='disable' name='csske'/> </cpu> New Nested Element Under <cpu> ------------------------------ Create a new optional XML element nested under the <cpu> tag that may be used to disable deprecated features. This approach is more explicit compared to creating a new CPU model, and allows the user to disable these features when defining a specific model other than host-model. Here is an example of what the guest's defined XML for the CPU could look like: <cpu mode='host-model' check='partial'> <deprecated_features>off</deprecated_features> </cpu> However, a conflict arises with this approach: parameter priority. It would need to be discussed what the expected behavior should be if a user defines a guest with both a mode to disable deprecated features and any deprecated features listed with the 'require' policy, e.g.: <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>z13.2-base</model>  <deprecated_features>off</deprecated_features> <feature policy='require' name='csske'/> </cpu> Another conflict is setting this option to "on" would have no effect on the CPU model (I can't think of a reason why someone would want to explicitly enable these features). This may not communicate well to the user. To report these features, a <deprecatedProperties> tag could be added to the domcapabilities output using the same format I use in my proposed patch for the qemu capabilities file: <cpu> <mode name='host-passthrough' supported='yes'> ... </mode> ... <mode name='host-model' supported='yes'> ... </mode> <deprecatedProperties> <property name='bpb'/> <property name='te'/> <property name='cte'/> <property name='csske'/> </deprecatedProperties> </cpu> Please let me know your thoughts. Once an approach is agreed upon, I will begin development. Collin Walling (1): qemu: monitor: parse deprecated-props from query-cpu-model-expansion response src/qemu/qemu_capabilities.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 2 ++ src/qemu/qemu_monitor_json.c | 29 ++++++++++++++++++++++++----- 3 files changed, 56 insertions(+), 5 deletions(-) -- 2.43.0

3 8

[PATCH v2 00/20] node_dev_udev: use workerpool and improve nodedev events
by Marc Hartmayer 19 Jun '24

19 Jun '24

When an udev event occurs for a mediated device (mdev) the mdev config data requires an update via mdevctl as the udev event does not contain all config data. This update needs to occur immediately and to be finished before the libvirt nodedev event is issued to keep the API usage reliable. Changelog: v1->v2: + squashed old patches 3 and 17 (comments from Jonathon and Boris) + added r-b's from Jonathon and Boris + worked in comments from Jonathon to old patch 15 + added comment why only one worker can currently be used + added patch `node_device_udev: remove incorrect G_GNUC_UNUSED` RFCv1->v1: + removed some of my own s-o-b's that were accidentally inserted in the RFC + added r-b's from Boris and Jonathon + worked in comments from Boris and Jonathon, but I did not inline "nodeDeviceDefResetMdevActiveConfig" as I'm not sure whether this improves the readability + reworked patch "[RFC PATCH v1 11/15] node_device_udev: Use `stateShutdownPrepare` and `stateShutdownWait`" + reworked patch "node_device_udev: Use a worker pool for processing events and emitting nodedev event" + added patches: - node_device_udev: Move responsibility to release `(init|udev)Thread` to `udevEventDataDispose` - node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and mdevCtlMonitor - node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly - node_device_udev: Pass the driver state as parameter in prepartion for the next commit - node_device_udev: Add support for `g_autoptr` to `udevEventData - node_device_udev: Pass the `udevEventData` via parameter and use refcounting Boris Fiuczynski (3): nodedev: fix mdev add udev event data handling nodedev: immediate update of active config on udev events nodedev: reset active config data on udev remove event Marc Hartmayer (17): node_device_udev: Set @def to NULL node_device_udev: Remove the timeout if the data is disposed node_device_udev: Test for mdevctlTimeout != -1 node_device_udev: Don't take `mdevctlLock` for `mdevctl list` and add comments about locking node_device_udev: Take lock if `driver->privateData` is modified node_device_udev: Add prefix `udev` for udev related data node_device_udev: Inline `udevRemoveOneDevice` node_device_udev: Move responsibility to release `(init|udev)Thread` to `udevEventDataDispose` node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and mdevCtlMonitors node_device_udev: Introduce and use `stateShutdownPrepare` and `stateShutdownWait` node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly node_device_udev: Pass the driver state as parameter in preparation for the next commit node_device_udev: Use a worker pool for processing events and emitting nodedev event node_device_udev: Make the code easier to read node_device_udev: Add support for `g_autoptr` to `udevEventData` node_device_udev: Pass the `udevEventData` via parameter and use refcounting node_device_udev: remove incorrect G_GNUC_UNUSED src/node_device/node_device_driver.h | 5 +- src/util/virmdev.h | 4 + src/conf/node_device_conf.c | 10 +- src/node_device/node_device_driver.c | 28 +- src/node_device/node_device_udev.c | 516 ++++++++++++++++++--------- src/test/test_driver.c | 11 +- src/util/virmdev.c | 20 ++ src/libvirt_private.syms | 2 + 8 files changed, 398 insertions(+), 198 deletions(-) base-commit: c38720b337f74337ec94c0fe2e97a7c2c57188ae -- 2.34.1

3 27

[PATCH 0/2] Make affinity setting a bit more debug friendly
by Michal Privoznik 17 Jun '24

17 Jun '24

*** BLURB HERE *** Michal Prívozník (2): qemu_process: Issue an info message when subtracting isolcpus virprocess: Debug affinity map in virProcessSetAffinity() src/qemu/qemu_process.c | 6 ++++++ src/util/virprocess.c | 6 ++++-- 2 files changed, 10 insertions(+), 2 deletions(-) -- 2.43.2

3 4

[libvirt PATCH 00/28] native support for nftables in virtual network driver
by Laine Stump 12 Jun '24

12 Jun '24

This patch series enables libvirt to use nftables rules rather than iptables *when setting up virtual networks* (it does *not* add nftables support to the nwfilter driver). It accomplishes this by abstracting several iptables functions (from viriptables.[ch] called by the virtual network driver into a rudimentary "virNetfilter API" (in virnetfilter.[ch], having the virtual network driver call the virNetFilter API rather than calling the existing iptables functions directly, and then finally adding an equivalent virNftables backend that can be used instead of iptables (selected manually via a network.conf setting, or automatically if iptables isn't found on the host). A first look at the result may have you thinking that it's filled with a lot of bad decisions. While I would agree with that in many cases, I think that overall they are the "least bad" decisions, or at least "bad within acceptable limits / no worse than something else", and point out that it's been done in a way that minimizes (actually eliminates) the need for immediate changes to nwfilter (the other consumer of iptables, which *also* needs to be updated to use native nftables), and makes it much easier to change our mind about the details in the future. When I first started on this (long, protracted, repeatedly interrupted for extended periods - many of these patches are > a year old) task, I considered doing an all-at-once complete replacement of iptables with nftables, since all the Linux distros we support have had nftables for several years, and I'm pretty sure nobody has it disabled (not even sure if it's possible to disable nftables while still enabling iptables, since they both use xtables in the kernel). But due to libvirt's use of "-t mangle -j CHECKSUM --checksum-fill" (see commit fd5b15ff all the way back in July 2010 for details) which has no equivalent in nftables rules (and we don't *want* it to!!), and the desire to be able to easily switch back to iptables in case of an unforeseen regression, we decided that both iptables and nftables need to be supported (for now), with the default (for now) remaining as iptables. Just allowing for dual backends complicated matters, since it means that we have to have a config file, a setting, detection of which backends are available, and of course some sort of concept of an abstracted frontend that can use either backend based on the config setting (and/or auto-detection). Combining that with the fact that it would just be "too big" of a project to switch over nwfilter's iptables usage at the same time means that we have to keep around a lot of existing code for compatibility's sake rather than just wiping it all away and starting over. So, what I've ended up with is: 1) a network.conf file (didn't exist before) with a single setting "firewall_backend". If unset, the network driver tries to use iptables on the backend, and if that's missing, then tries to use nftables. 2) a new (internal-only, so transient!) virNetFilterXXX API that is used by the network driver in place of the iptablesXXX API, and calls either iptablesXXX or: 3) a virNftablesXXX API that exactly replicates the filtering rules of the existing iptablesXXX API (except in the custom "libvirt" base table rather than the system "filter" and "nat" tables). This means that: 4) when the nftables backend is used, the rules added are *exactly the same* (functionally speaking) as we currently add for iptables (except they are in the "libvirt" table). We had spent some time in IRC discussing different ways of using new functionality available in nftables to make a more efficient/performant implemention of the desired filtering, and there are some really great possibilities that need to be explored, but in the end there were too many details up in the air, and I decided that it would be more "accomplishable" (coined a new word there!) to first replicate existing behavior with nftables, but do it inside a framework that makes it easy to modify the details in the future (in particular making it painless to switch back and forth between builds with differing filter models at runtime) - this way we'll be able to separate the infrastructure work from the details of the rules (which we can then more easily work on and experiment with). (This implies that the main objective right now is "get rid of iptables dependencies", not "make the filtering faster and more efficient"). Notable features of this patchset: * allows switching between iptables/nftables backends without rebooting or restarting networks/guests. Because the commands required to remove a network's filter rules are now saved in the network status XML, each time libvirtd (or virtnetworkd) is restarted, it will execute exactly the commands needed to remove the filter rules that had been added by the previous libvirtd/virtnetworkd (rather than just making a guess, as we've always done up until now), and then add new rules using the current backend+binary's set of rules (while also saving the info needed for future removal of these new rules back into the network's status XML). * firewall_backend can be explicitly set in (new) /etc/libvirt/network.conf, but if it's not explicitly set, libvirt will default to the iptables backend if the iptables binary is found, and otherwise fall back to nftables as long as the nft binary is found; otherwise the first attempt to start a network will fail with an appropriate error. Things that seem ugly / that I would like to clean up / that I think are just fine as they are: * virFirewall does *not* provide a backend-agnostic interface [this is fine] * We need to maintain a backward-compatible API for virFirewall so that we don't have to touch nwfilter code. Trying to make its API backend-agnostic would require individually considering/changing every nwfilter use of virFirewall. * instead virFirewall objects are just a way to build a collection of commands to execute to build a firewall, then execute them while collecting info for and building a collection of commands that will tear down that firewall in the future. Do I want to "fix" this in the future by making virFirewall a higher level interface that accepts tokens describing the type of rule to add (rather than backend-specific arguments to a backend-specific command)? No. I think I like the way virFirewall works (as described in that previous bullet-point), instead I'm thinking that it is just slightly mis-named - I've lately been thinking of it as a "virNetFilterCmdList". Similarly, the virFirewallRules that it has a list of aren't really "rules", they are better described as commands or actions, so maybe they should be renamed to virNetfilterCmd or virNetfilterAction. But that is just cosmetic, so I didn't want to get into it in these patches (especially in case someone disagrees, or has a better idea for naming). * Speaking of renaming - I should probably rename all the "iptablesXXX" functions to "virIptablesXXX" to be consistent with so much of our other code. I lost the ambition to deal with it right now though, so I'm leaving that for later cleanup (or I could do it now if it really makes someone's day :-). * I could have chosen a higher place in the callchain to make the virNetfilter abstraction, e.g. at the level of "networkAddXXXFirewallRules()" rather than at the lower level of iptablesXXX(). That is actually probably what will happen in the future (since it will be necessary in order for an nftables-based firewall to be significantly different in structure from an iptables-based firewall). But that's the beauty of an API being private - we can freely add/remove things as needed. the important thing is that we now have the basic structure there. For now, the split is just above the existing iptablesXXX API (util/viriptables.[ch], which seems like a "narrow" enough place. Most iptablesXXX functions are written in terms of just 10 *other* iptablesXXX functions that add iptables-specific commands - I've just moved those functions into virnetfilter.[ch] (appropriately renamed), and changed them to call the 10 virNetfilterXXX functions that will in-turn call those 10 iptablesXXX (or equivalent virNftablesXXX) functions. * Some people may dislike that the 10 virNetfilterXXX functions are each written with a switch statement that has cases to directly call each backend, rather than each backend driver having a table of pointers to API functions, with the virNetfilter API function calling backends[fwBackend]->XXX() (ie the pattern for so many drivers in libvirt). But for just 2 backends, that really seemed like overkill and unnecessary obfuscation. * As implemented here, I am storing a "<fwRemoval>" element in the network status XML - it contains a serialized virFirewall object that directly contains the commands necessary to remove the firewall. I could instead just store "<firewall>", which would include all the commands that were used to *create* the firewall in addition to the commands needed to remove the firewall. The way it's done currently takes up less space; switching to storing the full firewall *might* be more informative to somebody, but on the other hand would make the network status XML *very* long. If anybody has an opinion about this, now is the time to bring it up - do you think it's worth having a separate list of all the commands that were used to create a network's firewall (keeping in mind that there is no public API to access it)? Or is it enough to just store what's needed to remove the firewall? * Several months ago Eric Garver posted patches for a pure firewalld backend, and I requested that they not be pushed because I wanted that to be integrated with my nftables backend support. Due to the fact that the firewalld backend is almost entirely implemented by putting the bridge into a new firewalld "zone", with no individual rules added, that won't happen as just another backend driver file in parallel to iptables and nftables; it will instead work by checking firewall_backend at a higher level in the network driver, thus avoiding the calls to virNetfilterXXX() entirely. I have locally merged Eric's patches over the top of these patches, and there are surprisingly few conflicts, but since his patches didn't account for a user-settable config (but instead just always used the firewalld backend if firewalld was active), some of the patches are going to require a bit of rework, which I'll take care of after getting these patches in. Laine Stump (28): util: add -w/--concurrent when applying the rule rather than when building it util: new virFirewallRuleGet*() APIs util: determine ignoreErrors value when creating rule, not when applying util: rename iptables helpers that will become the frontend for ip&nftables util: move backend-agnostic virNetfilter*() functions to their own file util: make netfilter action a proper typedefed (virFirewall) enum util: #define the names used for private packet filter chains util: move/rename virFirewallApplyRuleDirect to virIptablesApplyFirewallRule util/network: reintroduce virFirewallBackend, but different network: add (empty) network.conf file to distribution files network: allow setting firewallBackend from network.conf network: do not add DHCP checksum mangle rule unless using iptables network: call backend agnostic function to init private filter chains util: setup functions in virnetfilter which will call appropriate backend build: add nft to the list of binaries we attempt to locate util: add nftables backend to virnetfilter API used by network driver tests: test cases for nftables backend util: new functions to support adding individual rollback rules util: check for 0 args when applying iptables rule util: implement rollback rule autosave for iptables backend util: implement rollback rule autosave for nftables backend network: turn on auto-rollback for the rules added for virtual networks util: new function virFirewallNewFromRollback() util: new functions virFirewallParseXML() and virFirewallFormat() conf: add a virFirewall object to virNetworkObj network: use previously saved list of firewall rules when removing network: save network status when firewall rules are reloaded network: improve log message when reloading virtual network firewall rules libvirt.spec.in | 5 + meson.build | 1 + po/POTFILES | 2 + src/conf/virnetworkobj.c | 40 + src/conf/virnetworkobj.h | 11 + src/libvirt_private.syms | 68 +- src/network/bridge_driver.c | 40 +- src/network/bridge_driver_conf.c | 44 + src/network/bridge_driver_conf.h | 3 + src/network/bridge_driver_linux.c | 241 +++-- src/network/bridge_driver_nop.c | 6 +- src/network/bridge_driver_platform.h | 6 +- src/network/libvirtd_network.aug | 39 + src/network/meson.build | 11 + src/network/network.conf | 24 + src/network/test_libvirtd_network.aug.in | 5 + src/nwfilter/nwfilter_ebiptables_driver.c | 16 +- src/util/meson.build | 2 + src/util/virebtables.c | 4 +- src/util/virfirewall.c | 490 ++++++++-- src/util/virfirewall.h | 51 +- src/util/viriptables.c | 762 ++++----------- src/util/viriptables.h | 222 ++--- src/util/virnetfilter.c | 892 ++++++++++++++++++ src/util/virnetfilter.h | 159 ++++ src/util/virnftables.c | 698 ++++++++++++++ src/util/virnftables.h | 118 +++ .../{base.args => base.iptables} | 0 tests/networkxml2firewalldata/base.nftables | 256 +++++ ...-linux.args => nat-default-linux.iptables} | 0 .../nat-default-linux.nftables | 248 +++++ ...pv6-linux.args => nat-ipv6-linux.iptables} | 0 .../nat-ipv6-linux.nftables | 384 ++++++++ ...rgs => nat-ipv6-masquerade-linux.iptables} | 0 .../nat-ipv6-masquerade-linux.nftables | 456 +++++++++ ...linux.args => nat-many-ips-linux.iptables} | 0 .../nat-many-ips-linux.nftables | 472 +++++++++ ...-linux.args => nat-no-dhcp-linux.iptables} | 0 .../nat-no-dhcp-linux.nftables | 384 ++++++++ ...ftp-linux.args => nat-tftp-linux.iptables} | 0 .../nat-tftp-linux.nftables | 274 ++++++ ...inux.args => route-default-linux.iptables} | 0 .../route-default-linux.nftables | 162 ++++ tests/networkxml2firewalltest.c | 56 +- tests/virfirewalltest.c | 20 +- 45 files changed, 5718 insertions(+), 954 deletions(-) create mode 100644 src/network/libvirtd_network.aug create mode 100644 src/network/network.conf create mode 100644 src/network/test_libvirtd_network.aug.in create mode 100644 src/util/virnetfilter.c create mode 100644 src/util/virnetfilter.h create mode 100644 src/util/virnftables.c create mode 100644 src/util/virnftables.h rename tests/networkxml2firewalldata/{base.args => base.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/base.nftables rename tests/networkxml2firewalldata/{nat-default-linux.args => nat-default-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-default-linux.nftables rename tests/networkxml2firewalldata/{nat-ipv6-linux.args => nat-ipv6-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-ipv6-linux.nftables rename tests/networkxml2firewalldata/{nat-ipv6-masquerade-linux.args => nat-ipv6-masquerade-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables rename tests/networkxml2firewalldata/{nat-many-ips-linux.args => nat-many-ips-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-many-ips-linux.nftables rename tests/networkxml2firewalldata/{nat-no-dhcp-linux.args => nat-no-dhcp-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-no-dhcp-linux.nftables rename tests/networkxml2firewalldata/{nat-tftp-linux.args => nat-tftp-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-tftp-linux.nftables rename tests/networkxml2firewalldata/{route-default-linux.args => route-default-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/route-default-linux.nftables -- 2.39.2

7 78

[PATCH RFC v2 00/12] Support throttle block filters
by wucf＠linux.ibm.com 12 Jun '24

12 Jun '24

From: Chun Feng Wu <wucf(a)linux.ibm.com> Hi, I am thinking to leverage "throttle block filter" in QEMU to support more flexible I/O limits(e.g. tiered I/O groups), one sample provided by QEMU doc is: https://github.com/qemu/qemu/blob/master/docs/throttle.txt "For example, let's say that we have three different drives and we want to set I/O limits for each one of them and an additional set of limits for the combined I/O of all three drives." The implementation idea is to - Define throttle groups(limit) in domain - Define throttle filter to reference throttle group within disk - Within domain disk, throttle filters references multiple throttle groups to form filter chain to apply multiple limits in QEMU like above sample - Add new virsh cmds for throttle group management: throttlegroupset Add or update a throttling group. throttlegroupdel Delete a throttling group. throttlegroupinfo Get a throttling group. throttlegrouplist list all domain throttlegroups - Update "attach-disk" to add one more option "--throttle-groups" to apply throttle filters e.g. "virsh attach-disk $VM_ID ${DISK_PATH}/vm1_disk_2.qcow2 vdd --driver qemu --subdriver qcow2 --targetbus virtio --throttle-groups limit2,limit012" - I chose above semantics as I felt they're appropriate, if there are better ones please kindly suggest. This patchset includes: - Throttle group and throttle filter definition in patch 1 - New QMP processing to update and get throttle group in patch 2 - New API definition and implementation in patch 3 - QEMU driver implementation in patch 4 - Hotplug and qemuProcessLaunch flow implemenation in patch 5,6 - Domain XML schema and doc(formatdomain.rst) change in patch 7 - Tests in patch 8,9 - Virsh cmd implementation in patch 10 - Other verification implementation in patch 11, 12 v2 changes: - fix failure caused by "check-remote_protocol" between patch 3 and patch 9 in v1 - make sure coding style is consistent about function declaration - patch 3 in v1 is splitted into two commits: "remote: New APIs for ThrottleGroup lifecycle management" and "qemu: Implement qemu driver for throttle API" - replace "// comment" with "/* comment */" - avoid empty 'cleanup' labels - use "virJSONValueObjectAdd(&limits, "P:name", value)" to avoid introducing extra helper, and check return value - preserve spacing between blocks of code which are not related - remove "VSH_OT_ALIAS" section for new cmds in virsh_domain.c From QMP perspective, the sample flow works this way: - Throttle group creation: virsh qemu-monitor-command 1 '{"execute":"object-add", "arguments":{"qom-type":"throttle-group","id":"limit0","limits":{"iops-total":200,"iops-read":0,"iops-total-max":200,"iops-total-max-length":1}}}' virsh qemu-monitor-command 1 '{"execute":"object-add", "arguments":{"qom-type":"throttle-group","id":"limit1","limits":{"iops-total":250,"iops-read":0,"iops-total-max":250,"iops-total-max-length":1}}}' virsh qemu-monitor-command 1 '{"execute":"object-add", "arguments":{"qom-type":"throttle-group","id":"limit2","limits":{"iops-total":300,"iops-read":0,"iops-total-max":300,"iops-total-max-length":1}}}' virsh qemu-monitor-command 1 '{"execute":"object-add", "arguments":{"qom-type":"throttle-group","id":"limit012","limits":{"iops-total":400,"iops-read":0,"iops-total-max":400,"iops-total-max-length":1}}}' - Chain up filters during attaching disk to apply two filters(limit0 and limit012): virsh qemu-monitor-command 1 '{"execute":"blockdev-add", "arguments": {"driver":"file","filename":"/virt/disks/vm1_disk_1.qcow2","node-name":"test-3-storage","auto-read-only":true,"discard":"unmap"}}' virsh qemu-monitor-command 1 '{"execute":"blockdev-add", "arguments":{"node-name":"test-3-format","read-only":false,"driver":"qcow2","file":"test-3-storage","backing":null}}' virsh qemu-monitor-command 1 '{"execute":"blockdev-add", "arguments":{"driver":"throttle","node-name":"libvirt-5-filter","throttle-group": "limit0","file":"test-3-format"}}' virsh qemu-monitor-command 1 '{"execute":"blockdev-add", "arguments": {"driver":"throttle","node-name":"libvirt-6-filter","throttle-group":"limit012","file":"libvirt-5-filter"}}' virsh qemu-monitor-command 1 '{"execute": "device_add", "arguments": {"driver":"virtio-blk-pci","scsi":false,"bus":"pci.0","addr":"0x5","drive":"libvirt-6-filter","id":"virtio-disk1"}}' Any comments/suggestions will be appriciated! Chun Feng Wu (10): config: Introduce ThrottleGroup and ThrottleFilter qemu: monitor: Add support for ThrottleGroup operations remote: New APIs for ThrottleGroup lifecycle management qemu: Implement qemu driver for throttle API qemu: hotplug: Support hot attach block disk along with throttle filters qemu: command: Support throttle groups and filters during qemuProcessLaunch schema: Add new domain elements to support multiple throttle filters test: Test throttle group lifecycle APIs tests: Test qemuMonitorJSONGetThrottleGroup and qemuMonitorJSONUpdateThrottleGroup virsh: Add support for throttle group operations Hao Ning Xin (1): config: validate: Verify throttle group fields Yan Xiu Wu (1): config: validate: Use "iotune" and "throttlefilters" exclusively for specific disk docs/formatdomain.rst | 48 ++ include/libvirt/libvirt-domain.h | 29 + src/conf/domain_conf.c | 386 +++++++++++++ src/conf/domain_conf.h | 54 ++ src/conf/domain_validate.c | 120 ++-- src/conf/schemas/domaincommon.rng | 164 +++++- src/conf/virconftypes.h | 4 + src/driver-hypervisor.h | 22 + src/libvirt-domain.c | 190 +++++++ src/libvirt_private.syms | 9 + src/libvirt_public.syms | 7 + src/qemu/qemu_block.c | 131 +++++ src/qemu/qemu_block.h | 53 ++ src/qemu/qemu_command.c | 158 ++++++ src/qemu/qemu_command.h | 9 + src/qemu/qemu_domain.c | 85 +++ src/qemu/qemu_domain.h | 15 + src/qemu/qemu_driver.c | 529 ++++++++++++++++++ src/qemu/qemu_hotplug.c | 24 + src/qemu/qemu_monitor.c | 34 ++ src/qemu/qemu_monitor.h | 14 + src/qemu/qemu_monitor_json.c | 151 +++++ src/qemu/qemu_monitor_json.h | 14 + src/remote/remote_daemon_dispatch.c | 61 ++ src/remote/remote_driver.c | 49 ++ src/remote/remote_protocol.x | 50 +- src/remote_protocol-structs | 30 + src/test/test_driver.c | 382 +++++++++++++ tests/qemumonitorjsontest.c | 88 +++ .../qemustatusxml2xmldata/backup-pull-in.xml | 1 + .../blockjob-blockdev-in.xml | 1 + .../blockjob-mirror-in.xml | 1 + .../migration-in-params-in.xml | 1 + .../migration-out-nbd-bitmaps-in.xml | 1 + .../migration-out-nbd-out.xml | 1 + .../migration-out-nbd-tls-out.xml | 1 + .../migration-out-params-in.xml | 1 + tests/qemustatusxml2xmldata/modern-in.xml | 1 + tests/qemustatusxml2xmldata/upgrade-out.xml | 1 + .../qemustatusxml2xmldata/vcpus-multi-in.xml | 1 + tools/virsh-completer-domain.c | 64 +++ tools/virsh-completer-domain.h | 10 + tools/virsh-domain.c | 471 ++++++++++++++++ 43 files changed, 3430 insertions(+), 36 deletions(-) -- 2.34.1

3 39

[PATCH-for-9.1 v2 0/3] rdma: Remove RDMA subsystem and pvrdma device
by Philippe Mathieu-Daudé 07 Jun '24

07 Jun '24

Since v1: - split in 3 (Thomas) - justify gluster removal Philippe Mathieu-Daudé (3): hw/rdma: Remove pvrdma device and rdmacm-mux helper migration: Remove RDMA protocol handling block/gluster: Remove RDMA protocol handling MAINTAINERS | 17 - docs/about/deprecated.rst | 9 - docs/about/removed-features.rst | 4 + docs/devel/migration/main.rst | 6 - docs/pvrdma.txt | 345 -- docs/rdma.txt | 420 -- docs/system/device-url-syntax.rst.inc | 4 +- docs/system/loongarch/virt.rst | 2 +- docs/system/qemu-block-drivers.rst.inc | 1 - meson.build | 59 - qapi/machine.json | 17 - qapi/migration.json | 31 +- qapi/qapi-schema.json | 1 - qapi/rdma.json | 38 - contrib/rdmacm-mux/rdmacm-mux.h | 61 - hw/rdma/rdma_backend.h | 129 - hw/rdma/rdma_backend_defs.h | 76 - hw/rdma/rdma_rm.h | 97 - hw/rdma/rdma_rm_defs.h | 146 - hw/rdma/rdma_utils.h | 63 - hw/rdma/trace.h | 1 - hw/rdma/vmw/pvrdma.h | 144 - hw/rdma/vmw/pvrdma_dev_ring.h | 46 - hw/rdma/vmw/pvrdma_qp_ops.h | 28 - hw/rdma/vmw/trace.h | 1 - include/hw/rdma/rdma.h | 37 - include/monitor/hmp.h | 1 - .../infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h | 685 --- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 348 -- .../standard-headers/rdma/vmw_pvrdma-abi.h | 310 -- migration/migration-stats.h | 6 +- migration/migration.h | 9 - migration/options.h | 2 - migration/rdma.h | 69 - block/gluster.c | 39 - contrib/rdmacm-mux/main.c | 831 ---- hw/core/machine-qmp-cmds.c | 32 - hw/rdma/rdma.c | 30 - hw/rdma/rdma_backend.c | 1401 ------ hw/rdma/rdma_rm.c | 812 ---- hw/rdma/rdma_utils.c | 126 - hw/rdma/vmw/pvrdma_cmd.c | 815 ---- hw/rdma/vmw/pvrdma_dev_ring.c | 141 - hw/rdma/vmw/pvrdma_main.c | 735 --- hw/rdma/vmw/pvrdma_qp_ops.c | 298 -- migration/migration-stats.c | 5 +- migration/migration.c | 31 - migration/options.c | 16 - migration/qemu-file.c | 1 - migration/ram.c | 86 +- migration/rdma.c | 4184 ----------------- migration/savevm.c | 2 +- monitor/qmp-cmds.c | 1 - Kconfig.host | 3 - contrib/rdmacm-mux/meson.build | 7 - hmp-commands-info.hx | 13 - hw/Kconfig | 1 - hw/meson.build | 1 - hw/rdma/Kconfig | 3 - hw/rdma/meson.build | 12 - hw/rdma/trace-events | 31 - hw/rdma/vmw/trace-events | 17 - meson_options.txt | 4 - migration/meson.build | 1 - migration/trace-events | 68 +- qapi/meson.build | 1 - qemu-options.hx | 6 - .../org.centos/stream/8/build-environment.yml | 1 - .../ci/org.centos/stream/8/x86_64/configure | 3 - scripts/ci/setup/build-environment.yml | 4 - scripts/coverity-scan/run-coverity-scan | 2 +- scripts/meson-buildoptions.sh | 6 - scripts/update-linux-headers.sh | 27 - tests/lcitool/projects/qemu.yml | 3 - tests/migration/guestperf/engine.py | 4 +- 75 files changed, 20 insertions(+), 12997 deletions(-) delete mode 100644 docs/pvrdma.txt delete mode 100644 docs/rdma.txt delete mode 100644 qapi/rdma.json delete mode 100644 contrib/rdmacm-mux/rdmacm-mux.h delete mode 100644 hw/rdma/rdma_backend.h delete mode 100644 hw/rdma/rdma_backend_defs.h delete mode 100644 hw/rdma/rdma_rm.h delete mode 100644 hw/rdma/rdma_rm_defs.h delete mode 100644 hw/rdma/rdma_utils.h delete mode 100644 hw/rdma/trace.h delete mode 100644 hw/rdma/vmw/pvrdma.h delete mode 100644 hw/rdma/vmw/pvrdma_dev_ring.h delete mode 100644 hw/rdma/vmw/pvrdma_qp_ops.h delete mode 100644 hw/rdma/vmw/trace.h delete mode 100644 include/hw/rdma/rdma.h delete mode 100644 include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h delete mode 100644 include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h delete mode 100644 include/standard-headers/rdma/vmw_pvrdma-abi.h delete mode 100644 migration/rdma.h delete mode 100644 contrib/rdmacm-mux/main.c delete mode 100644 hw/rdma/rdma.c delete mode 100644 hw/rdma/rdma_backend.c delete mode 100644 hw/rdma/rdma_rm.c delete mode 100644 hw/rdma/rdma_utils.c delete mode 100644 hw/rdma/vmw/pvrdma_cmd.c delete mode 100644 hw/rdma/vmw/pvrdma_dev_ring.c delete mode 100644 hw/rdma/vmw/pvrdma_main.c delete mode 100644 hw/rdma/vmw/pvrdma_qp_ops.c delete mode 100644 migration/rdma.c delete mode 100644 contrib/rdmacm-mux/meson.build delete mode 100644 hw/rdma/Kconfig delete mode 100644 hw/rdma/meson.build delete mode 100644 hw/rdma/trace-events delete mode 100644 hw/rdma/vmw/trace-events -- 2.41.0

17 80

[PATCH 0/3] qemu: Use TPM 2.0 on RISC-V
by Andrea Bolognani 03 Jun '24

03 Jun '24

Andrea Bolognani (3): tests: Add TPM coverage to default-models tests tests: Delete some redundant test cases qemu: Only allow TPM 2.0 for RISC-V guests src/qemu/qemu_domain.c | 1 + src/qemu/qemu_validate.c | 10 +-- ...aarch64-tpm-wrong-model.aarch64-latest.err | 2 +- .../aarch64-tpm.aarch64-latest.args | 34 --------- .../aarch64-tpm.aarch64-latest.xml | 29 -------- tests/qemuxmlconfdata/aarch64-tpm.xml | 15 ---- ...ault-models.aarch64-latest.abi-update.args | 3 + ...fault-models.aarch64-latest.abi-update.xml | 3 + ...64-virt-default-models.aarch64-latest.args | 3 + ...h64-virt-default-models.aarch64-latest.xml | 3 + .../aarch64-virt-default-models.xml | 3 + .../loongarch64-virt-default-models.xml | 1 + ...efault-models.ppc64-latest.abi-update.args | 3 + ...default-models.ppc64-latest.abi-update.xml | 4 ++ ...4-pseries-default-models.ppc64-latest.args | 3 + ...64-pseries-default-models.ppc64-latest.xml | 4 ++ .../ppc64-pseries-default-models.xml | 3 + ...ault-models.riscv64-latest.abi-update.args | 3 + ...fault-models.riscv64-latest.abi-update.xml | 3 + ...64-virt-default-models.riscv64-latest.args | 3 + ...v64-virt-default-models.riscv64-latest.xml | 3 + .../riscv64-virt-default-models.xml | 3 + .../s390x-ccw-default-models.xml | 1 + .../tpm-emulator-spapr.ppc64-latest.args | 45 ------------ .../tpm-emulator-spapr.ppc64-latest.xml | 1 - tests/qemuxmlconfdata/tpm-emulator-spapr.xml | 70 ------------------- ...fault-models.x86_64-latest.abi-update.args | 3 + ...efault-models.x86_64-latest.abi-update.xml | 3 + ...86_64-pc-default-models.x86_64-latest.args | 3 + ...x86_64-pc-default-models.x86_64-latest.xml | 3 + .../x86_64-pc-default-models.xml | 3 + ...fault-models.x86_64-latest.abi-update.args | 3 + ...efault-models.x86_64-latest.abi-update.xml | 3 + ...6_64-q35-default-models.x86_64-latest.args | 3 + ...86_64-q35-default-models.x86_64-latest.xml | 3 + .../x86_64-q35-default-models.xml | 3 + tests/qemuxmlconftest.c | 2 - 37 files changed, 87 insertions(+), 201 deletions(-) delete mode 100644 tests/qemuxmlconfdata/aarch64-tpm.aarch64-latest.args delete mode 100644 tests/qemuxmlconfdata/aarch64-tpm.aarch64-latest.xml delete mode 100644 tests/qemuxmlconfdata/aarch64-tpm.xml delete mode 100644 tests/qemuxmlconfdata/tpm-emulator-spapr.ppc64-latest.args delete mode 120000 tests/qemuxmlconfdata/tpm-emulator-spapr.ppc64-latest.xml delete mode 100644 tests/qemuxmlconfdata/tpm-emulator-spapr.xml -- 2.45.1

3 9

[PATCH] qga: Remove deprecated 'blacklist' argument / config key
by Philippe Mathieu-Daudé 03 Jun '24

03 Jun '24

The 'blacklist' argument / config key are deprecated since commi 582a098e6c ("qga: Replace 'blacklist' command line and config file options by 'block-rpcs'"), time to remove them. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- docs/about/deprecated.rst | 18 ------------------ docs/about/removed-features.rst | 18 ++++++++++++++++++ qga/main.c | 6 ------ 3 files changed, 18 insertions(+), 24 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 40585ca7d5..a32e0e2564 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -478,24 +478,6 @@ versions, aliases will point to newer CPU model versions depending on the machine type, so management software must resolve CPU model aliases before starting a virtual machine. -QEMU guest agent ----------------- - -``--blacklist`` command line option (since 7.2) -''''''''''''''''''''''''''''''''''''''''''''''' - -``--blacklist`` has been replaced by ``--block-rpcs`` (which is a better -wording for what this option does). The short form ``-b`` still stays -the same and thus is the preferred way for scripts that should run with -both, older and future versions of QEMU. - -``blacklist`` config file option (since 7.2) -'''''''''''''''''''''''''''''''''''''''''''' - -The ``blacklist`` config file option has been renamed to ``block-rpcs`` -(to be in sync with the renaming of the corresponding command line -option). - Migration --------- diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index fba0cfb0b0..deca066b21 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -1129,4 +1129,22 @@ stable for some time and is now widely used. The command line and feature set is very close to the removed C implementation. +QEMU guest agent +---------------- + +``--blacklist`` command line option (removed in 9.1) +'''''''''''''''''''''''''''''''''''''''''''''''''''' + +``--blacklist`` has been replaced by ``--block-rpcs`` (which is a better +wording for what this option does). The short form ``-b`` still stays +the same and thus is the preferred way for scripts that should run with +both, older and future versions of QEMU. + +``blacklist`` config file option (removed in 9.1) +''''''''''''''''''''''''''''''''''''''''''''''''' + +The ``blacklist`` config file option has been renamed to ``block-rpcs`` +(to be in sync with the renaming of the corresponding command line +option). + .. _Intel discontinuance notification: https://www.intel.com/content/www/us/en/content-details/781327/intel-is-dis… diff --git a/qga/main.c b/qga/main.c index bdf5344584..f4d5f15bb3 100644 --- a/qga/main.c +++ b/qga/main.c @@ -1071,11 +1071,6 @@ static void config_load(GAConfig *config) g_key_file_get_boolean(keyfile, "general", "retry-path", &gerr); } - if (g_key_file_has_key(keyfile, "general", "blacklist", NULL)) { - g_warning("config using deprecated 'blacklist' key, should be replaced" - " with the 'block-rpcs' key."); - blockrpcs_key = "blacklist"; - } if (g_key_file_has_key(keyfile, "general", blockrpcs_key, NULL)) { config->bliststr = g_key_file_get_string(keyfile, "general", blockrpcs_key, &gerr); @@ -1190,7 +1185,6 @@ static void config_parse(GAConfig *config, int argc, char **argv) { "path", 1, NULL, 'p' }, { "daemonize", 0, NULL, 'd' }, { "block-rpcs", 1, NULL, 'b' }, - { "blacklist", 1, NULL, 'b' }, /* deprecated alias for 'block-rpcs' */ { "allow-rpcs", 1, NULL, 'a' }, #ifdef _WIN32 { "service", 1, NULL, 's' }, -- 2.41.0

2 3

[PATCH 0/2] qapi: Remove deprecated events
by Philippe Mathieu-Daudé 03 Jun '24

03 Jun '24

Remove MEM_UNPLUG_ERROR and 'vcpu' field in TRACE events, all deprecated since long enough. Philippe Mathieu-Daudé (2): hw/acpi: Remove the deprecated QAPI MEM_UNPLUG_ERROR event trace: Remove deprecated 'vcpu' field from QMP trace events docs/about/deprecated.rst | 16 ---------------- docs/about/removed-features.rst | 15 +++++++++++++++ qapi/machine.json | 28 ---------------------------- qapi/trace.json | 27 +++------------------------ hw/acpi/memory_hotplug.c | 8 -------- hw/ppc/spapr.c | 11 +---------- trace/qmp.c | 2 -- trace/trace-hmp-cmds.c | 4 ++-- 8 files changed, 21 insertions(+), 90 deletions(-) -- 2.41.0

4 6

[PATCH 0/3] meson: Improve default firewall backend configuration
by Andrea Bolognani 03 Jun '24

03 Jun '24

Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1308917840 See 1/3 for details. Andrea Bolognani (3): meson: Improve default firewall backend configuration meson: Include firewall backend selection in summary rpm: Configure firewall backends explicitly libvirt.spec.in | 1 + meson.build | 21 ++++++++++++++------- meson_options.txt | 3 +-- src/network/bridge_driver_conf.c | 6 +++++- src/network/meson.build | 6 ++++-- src/network/network.conf.in | 13 +++++++------ 6 files changed, 32 insertions(+), 18 deletions(-) -- 2.45.1

4 14