[libvirt PATCH 00/28] native support for nftables in virtual network driver
by Laine Stump
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
6 months, 2 weeks
[PATCH] Extend libvirt-guests to shutdown only persistent VMs
by Benjamin Taubmann
At the moment, there is no configuration option for the libvirt-guests
service that allows users to define that only persistent virtual machines
should be shutdown on host shutdown.
Currently, the service config allows to choose between two ON_SHUTDOWN
actions that are executed on running virtual machines when the host goes
down: shutdown, suspend.
The ON_SHUTDOWN action should be orthogonal to the type of the virtual
machine. However, the existing implementation, does not suspend
transient virtual machines.
This is the matrix of actions that is executed on virtual machines based
on the configured ON_SHUTDOWN action and the type of a virtual machine.
| persistent | transient
shutdown | shutdown | shutdown (what we want to change)
suspend | suspend | nothing
Add config option PERSISTENT_ONLY to libvirt-guests config that allows
users to define if the ON_SHUTDOWN action should be applied only on
persistent virtual machines. PERSISTENT_ONLY can be set to true, false,
default. The default option will implement the already existing logic.
Case 1: PERSISTENT_ONLY=default
| persistent | transient
shutdown | shutdown | shutdown
suspend | suspend | nothing
Case 2: PERSISTENT_ONLY=true
| persistent | transient
shutdown | shutdown | nothing
suspend | suspend | nothing
Case 3: PERSISTENT_ONLY=false
| persistent | transient
shutdown | shutdown | shutdown
suspend | suspend | suspend
Change-Id: Ib03013d00b3ec60716287dad4743a038cf000763
---
tools/libvirt-guests.sh.in | 37 ++++++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in
index 344b54390a..c3c5954e17 100644
--- a/tools/libvirt-guests.sh.in
+++ b/tools/libvirt-guests.sh.in
@@ -38,6 +38,7 @@ PARALLEL_SHUTDOWN=0
START_DELAY=0
BYPASS_CACHE=0
SYNC_TIME=0
+PERSISTENT_ONLY="default"
test -f "$initconfdir"/libvirt-guests &&
. "$initconfdir"/libvirt-guests
@@ -438,14 +439,16 @@ shutdown_guests_parallel()
# stop
# Shutdown or save guests on the configured uris
stop() {
- local suspending="true"
local uri=
+ local action="suspend"
+ local persistent_only="default"
+
# last stop was not followed by start
[ -f "$LISTFILE" ] && return 0
if [ "x$ON_SHUTDOWN" = xshutdown ]; then
- suspending="false"
+ action="shutdown"
if [ $SHUTDOWN_TIMEOUT -lt 0 ]; then
gettext "SHUTDOWN_TIMEOUT must be equal or greater than 0"
echo
@@ -454,6 +457,22 @@ stop() {
fi
fi
+ case "x$PERSISTENT_ONLY" in
+ xtrue)
+ persistent_only="true"
+ ;;
+ xfalse)
+ persistent_only="false"
+ ;;
+ *)
+ if [ "x$action" = xshutdown ]; then
+ persistent_only="false"
+ elif [ "x$action" = xsuspend ]; then
+ persistent_only="true"
+ fi
+ ;;
+ esac
+
: >"$LISTFILE"
set -f
for uri in $URIS; do
@@ -478,7 +497,7 @@ stop() {
echo
fi
- if "$suspending"; then
+ if "$persistent_only"; then
local transient="$(list_guests "$uri" "--transient")"
if [ $? -eq 0 ]; then
local empty="true"
@@ -486,7 +505,11 @@ stop() {
for uuid in $transient; do
if "$empty"; then
- eval_gettext "Not suspending transient guests on URI: \$uri: "
+ if [ "x$action" = xsuspend ]; then
+ eval_gettext "Not suspending transient guests on URI: \$uri: "
+ else
+ eval_gettext "Not shutting down transient guests on URI: \$uri: "
+ fi
empty="false"
else
printf ", "
@@ -520,19 +543,19 @@ stop() {
if [ -s "$LISTFILE" ]; then
while read uri list; do
- if "$suspending"; then
+ if [ "x$action" = xsuspend ]; then
eval_gettext "Suspending guests on \$uri URI..."; echo
else
eval_gettext "Shutting down guests on \$uri URI..."; echo
fi
if [ "$PARALLEL_SHUTDOWN" -gt 1 ] &&
- ! "$suspending"; then
+ [ "x$action" = xshutdown ]; then
shutdown_guests_parallel "$uri" "$list"
else
local guest=
for guest in $list; do
- if "$suspending"; then
+ if [ "x$action" = xsuspend ]; then
suspend_guest "$uri" "$guest"
else
shutdown_guest "$uri" "$guest"
--
2.39.2
8 months, 3 weeks
[PATCH v3 00/12] Improve versioned CPU support in libvirt
by Jonathon Jongsma
For SEV-SNP support we will need to be able to specify versioned CPU models
that are not yet available in libvirt. Rather than just adding a versioned CPU
or two that would satisfy that immediate need, I decided to try to add
versioned CPUs in a more standard way. This series generates CPU definitions
for all cpu versions that are defined in upstream qemu (at least for
recent Intel and AMD CPUs).
libvirt already provides a select subset of these versions as configurable CPU
models. But we only include the ones that have defined aliases in qemu, such as
EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu
will be available in libvirt.
In addition to adding these new versioned models, based on feedback from Daniel
Berrange, I've also translated all CPU model aliases to a specific version when
specifying a CPU model to qemu. This means that we will no longer specify e.g.
'-cpu EPYC' to qemu, but will rather specify '-cpu EPYC-v1'
Changes in v3:
- handle unversioned aliases
Changes in v2:
- don't make any changes to existing CPU models
- drop concept of aliases from libvirt and only provide new versioned models
that aren't already available via their qemu alias.
Jonathon Jongsma (12):
cpu_map: update script to handle versioned CPUs
cpu_map: add canonical names to existing CPU models
cpu: parse the canonical name from the cpu model
qemu: use canonical name for CPU models
cpu_map: Add versioned EPYC CPUs
cpu_map: Add versioned Intel Skylake CPUs
cpu_map: Add versioned Intel Cascadelake CPUs
cpu_map: Add versioned Intel Icelake CPUs
cpu_map: Add versioned Intel Cooperlake CPUs
cpu_map: Add versioned Intel Snowridge CPUs
cpu_map: Add versioned Intel SapphireRapids CPUs
cpu_map: Add versioned Dhyana CPUs
src/conf/cpu_conf.c | 3 +
src/conf/cpu_conf.h | 1 +
src/cpu/cpu_x86.c | 24 ++++
src/cpu_map/index.xml | 22 +++
src/cpu_map/meson.build | 22 +++
src/cpu_map/sync_qemu_models_i386.py | 42 ++++--
src/cpu_map/x86_Broadwell-IBRS.xml | 1 +
src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 1 +
src/cpu_map/x86_Broadwell-noTSX.xml | 1 +
src/cpu_map/x86_Broadwell.xml | 1 +
src/cpu_map/x86_Cascadelake-Server-noTSX.xml | 1 +
src/cpu_map/x86_Cascadelake-Server-v2.xml | 93 +++++++++++++
src/cpu_map/x86_Cascadelake-Server-v4.xml | 91 +++++++++++++
src/cpu_map/x86_Cascadelake-Server-v5.xml | 92 +++++++++++++
src/cpu_map/x86_Cascadelake-Server.xml | 1 +
src/cpu_map/x86_Cooperlake-v2.xml | 98 ++++++++++++++
src/cpu_map/x86_Cooperlake.xml | 1 +
src/cpu_map/x86_Dhyana-v2.xml | 81 ++++++++++++
src/cpu_map/x86_Dhyana.xml | 1 +
src/cpu_map/x86_EPYC-IBPB.xml | 1 +
src/cpu_map/x86_EPYC-Milan-v2.xml | 108 +++++++++++++++
src/cpu_map/x86_EPYC-Milan.xml | 1 +
src/cpu_map/x86_EPYC-Rome-v2.xml | 93 +++++++++++++
src/cpu_map/x86_EPYC-Rome-v3.xml | 95 +++++++++++++
src/cpu_map/x86_EPYC-Rome-v4.xml | 94 +++++++++++++
src/cpu_map/x86_EPYC-Rome.xml | 1 +
src/cpu_map/x86_EPYC-v3.xml | 87 ++++++++++++
src/cpu_map/x86_EPYC-v4.xml | 88 ++++++++++++
src/cpu_map/x86_EPYC.xml | 1 +
src/cpu_map/x86_Haswell-IBRS.xml | 1 +
src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 1 +
src/cpu_map/x86_Haswell-noTSX.xml | 1 +
src/cpu_map/x86_Haswell.xml | 1 +
src/cpu_map/x86_Icelake-Server-noTSX.xml | 1 +
src/cpu_map/x86_Icelake-Server-v3.xml | 103 +++++++++++++++
src/cpu_map/x86_Icelake-Server-v4.xml | 108 +++++++++++++++
src/cpu_map/x86_Icelake-Server-v5.xml | 109 +++++++++++++++
src/cpu_map/x86_Icelake-Server-v6.xml | 109 +++++++++++++++
src/cpu_map/x86_Icelake-Server.xml | 1 +
src/cpu_map/x86_IvyBridge-IBRS.xml | 1 +
src/cpu_map/x86_IvyBridge.xml | 1 +
src/cpu_map/x86_Nehalem-IBRS.xml | 1 +
src/cpu_map/x86_Nehalem.xml | 1 +
src/cpu_map/x86_SandyBridge-IBRS.xml | 1 +
src/cpu_map/x86_SandyBridge.xml | 1 +
src/cpu_map/x86_SapphireRapids-v2.xml | 125 ++++++++++++++++++
src/cpu_map/x86_SapphireRapids.xml | 1 +
src/cpu_map/x86_Skylake-Client-IBRS.xml | 1 +
src/cpu_map/x86_Skylake-Client-noTSX-IBRS.xml | 1 +
src/cpu_map/x86_Skylake-Client-v4.xml | 77 +++++++++++
src/cpu_map/x86_Skylake-Client.xml | 1 +
src/cpu_map/x86_Skylake-Server-IBRS.xml | 1 +
src/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml | 1 +
src/cpu_map/x86_Skylake-Server-v4.xml | 83 ++++++++++++
src/cpu_map/x86_Skylake-Server-v5.xml | 85 ++++++++++++
src/cpu_map/x86_Skylake-Server.xml | 1 +
src/cpu_map/x86_Snowridge-v2.xml | 78 +++++++++++
src/cpu_map/x86_Snowridge-v3.xml | 80 +++++++++++
src/cpu_map/x86_Snowridge-v4.xml | 78 +++++++++++
src/cpu_map/x86_Snowridge.xml | 1 +
src/cpu_map/x86_Westmere-IBRS.xml | 1 +
src/cpu_map/x86_Westmere.xml | 1 +
src/qemu/qemu_command.c | 5 +-
.../x86_64-cpuid-Atom-P5362-guest.xml | 3 +-
.../x86_64-cpuid-Atom-P5362-json.xml | 3 +-
.../x86_64-cpuid-Cooperlake-host.xml | 3 +-
.../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +-
.../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 9 +-
...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +-
..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 5 +-
...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +-
...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 6 +-
...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 9 +-
.../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 9 +-
.../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 9 +-
.../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 9 +-
.../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 9 +-
.../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 9 +-
..._64-cpuid-baseline-Cascadelake+Icelake.xml | 9 +-
...-cpuid-baseline-Cooperlake+Cascadelake.xml | 9 +-
...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 9 +-
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 2 +
.../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 2 +
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 2 +
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 4 +
.../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 4 +
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 4 +
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 7 +
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 7 +
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 7 +
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 7 +
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 7 +
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 7 +
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 8 ++
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 8 ++
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 8 ++
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 15 +++
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 15 +++
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 15 +++
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 16 +++
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 16 +++
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 16 +++
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 17 +++
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 17 +++
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 17 +++
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 17 +++
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 17 +++
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 17 +++
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 17 +++
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 17 +++
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 17 +++
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 17 +++
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 17 +++
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 17 +++
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 17 +++
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 27 +++-
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 22 +++
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 27 +++-
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 27 +++-
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 22 +++
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 27 +++-
.../cpu-Haswell-noTSX.x86_64-latest.args | 2 +-
.../cpu-Haswell.x86_64-latest.args | 2 +-
.../cpu-Haswell2.x86_64-latest.args | 2 +-
.../cpu-Haswell3.x86_64-latest.args | 2 +-
...-Icelake-Server-pconfig.x86_64-latest.args | 2 +-
.../cpu-cache-disable3.x86_64-latest.args | 2 +-
...u-check-default-partial.x86_64-latest.args | 2 +-
.../cpu-fallback.x86_64-5.2.0.args | 2 +-
.../cpu-fallback.x86_64-8.0.0.args | 2 +-
.../cpu-host-model-cmt.x86_64-latest.args | 2 +-
...-host-model-fallback-kvm.x86_64-4.2.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-5.0.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-5.1.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-5.2.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-6.0.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-6.1.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-6.2.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-7.0.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-7.1.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-7.2.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-8.0.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-8.1.0.args | 2 +-
...host-model-fallback-kvm.x86_64-latest.args | 2 +-
...-host-model-fallback-tcg.x86_64-7.2.0.args | 2 +-
...-host-model-fallback-tcg.x86_64-8.0.0.args | 2 +-
...-host-model-fallback-tcg.x86_64-8.1.0.args | 2 +-
...host-model-fallback-tcg.x86_64-latest.args | 2 +-
.../cpu-host-model-kvm.x86_64-4.2.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-5.0.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-5.1.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-5.2.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-6.0.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-6.1.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-6.2.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-7.0.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-7.1.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-7.2.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-8.0.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-8.1.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-latest.args | 2 +-
...ost-model-nofallback-kvm.x86_64-4.2.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-5.0.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-5.1.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-5.2.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-6.0.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-6.1.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-6.2.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-7.0.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-7.1.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-7.2.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-8.0.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-8.1.0.args | 2 +-
...st-model-nofallback-kvm.x86_64-latest.args | 2 +-
...ost-model-nofallback-tcg.x86_64-7.2.0.args | 2 +-
...ost-model-nofallback-tcg.x86_64-8.0.0.args | 2 +-
...ost-model-nofallback-tcg.x86_64-8.1.0.args | 2 +-
...st-model-nofallback-tcg.x86_64-latest.args | 2 +-
.../cpu-host-model-tcg.x86_64-7.2.0.args | 2 +-
.../cpu-host-model-tcg.x86_64-8.0.0.args | 2 +-
.../cpu-host-model-tcg.x86_64-8.1.0.args | 2 +-
.../cpu-host-model-tcg.x86_64-latest.args | 2 +-
.../cpu-host-model-vendor.x86_64-latest.args | 2 +-
.../cpu-minimum1.x86_64-latest.args | 2 +-
.../cpu-minimum2.x86_64-latest.args | 2 +-
.../cpu-nofallback.x86_64-8.0.0.args | 2 +-
.../cpu-phys-bits-emulate2.x86_64-latest.args | 2 +-
.../cpu-strict1.x86_64-latest.args | 2 +-
.../cpu-translation.x86_64-latest.args | 2 +-
.../cpu-tsc-frequency.x86_64-latest.args | 2 +-
190 files changed, 2837 insertions(+), 187 deletions(-)
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml
create mode 100644 src/cpu_map/x86_Dhyana-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml
create mode 100644 src/cpu_map/x86_EPYC-v3.xml
create mode 100644 src/cpu_map/x86_EPYC-v4.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml
create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml
create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Snowridge-v2.xml
create mode 100644 src/cpu_map/x86_Snowridge-v3.xml
create mode 100644 src/cpu_map/x86_Snowridge-v4.xml
--
2.41.0
9 months, 1 week
[PATCH 0/7] qemu XML testing improvements, part 3 - xmlout->xmlout testing and fixes
by Peter Krempa
This series depends on the 'part 2' with cover letter's subject:
[PATCH 00/23] qemu XML testing improvements, part 2 - enforcement of xml->xml testing
both this along with the rebased prerequisite series can be fetched
from:
git fetch https://gitlab.com/pipo.sk/libvirt.git test-improvements-3
The main goal of part 3 is to add testing based on parsing of the
libvirt-formatted files from tests/qemuxml2xmloutdata and formatting
them back, and checking that they are identical.
By adding this testing multiple problems in code auto-adding information
was discovered.
Peter Krempa (7):
virDomainDefMaybeAddVirtioSerialController: Reformat hard to read
linebreaks
conf: domain: Insert auto-added controllers in same order as in XML
parser
virDomainAssignControllerIndexes: Ensure controller ordering after
assigning indexes
qemu: Move 'shmem' device size validation to qemu_validate
qemuDomainAssignPCIAddresses: Assign extension addresses when
auto-assigning PCI address
virDomainDefAddConsoleCompat: Fix numbering of console targets after
modification
qemuxml2conftest: Test re-parsing of formatted XML
src/conf/domain_conf.c | 26 ++++++++++---
src/conf/domain_postparse.c | 21 ++++++++++
src/qemu/qemu_command.c | 19 ----------
src/qemu/qemu_domain_address.c | 14 +++++--
src/qemu/qemu_validate.c | 9 +++++
.../autoindex.x86_64-latest.args | 4 +-
.../channel-virtio-default.x86_64-latest.args | 2 +-
.../channel-virtio-unix.x86_64-latest.args | 2 +-
.../chardev-reconnect.x86_64-latest.args | 2 +-
.../pci-autoadd-idx.x86_64-latest.args | 16 ++++----
.../pseries-many-buses-2.ppc64-latest.args | 4 +-
.../shmem-invalid-size.x86_64-latest.err | 2 +-
.../shmem-small-size.x86_64-latest.err | 2 +-
.../aarch64-virt-graphics.aarch64-latest.xml | 6 +--
.../aarch64-virt-headless.aarch64-latest.xml | 6 +--
.../aarch64-virt-virtio.aarch64-4.2.0.xml | 6 +--
.../aarch64-virt-virtio.aarch64-latest.xml | 6 +--
...rch64-virtio-pci-default.aarch64-4.2.0.xml | 6 +--
...ch64-virtio-pci-default.aarch64-latest.xml | 6 +--
...io-pci-manual-addresses.aarch64-latest.xml | 6 +--
.../arm-virt-virtio.aarch64-latest.xml | 6 +--
.../autoindex.x86_64-latest.xml | 12 +++---
.../channel-virtio-auto.x86_64-latest.xml | 2 +-
.../channel-virtio-autoadd.x86_64-latest.xml | 2 +-
.../channel-virtio-default.x86_64-latest.xml | 6 +--
.../channel-virtio-unix.x86_64-latest.xml | 6 +--
.../chardev-reconnect.x86_64-latest.xml | 6 +--
.../console-compat2.x86_64-latest.xml | 2 +-
.../cpu-host-model-kvm.x86_64-4.2.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-5.0.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-5.1.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-5.2.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-6.0.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-6.1.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-6.2.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-7.0.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-7.1.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-7.2.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-8.0.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-8.1.0.xml | 12 +++---
.../cpu-host-model-kvm.x86_64-latest.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-4.2.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-5.0.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-5.1.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-5.2.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-6.0.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-6.1.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-6.2.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-7.0.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-7.1.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-7.2.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-8.0.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-8.1.0.xml | 12 +++---
.../cpu-host-model-tcg.x86_64-latest.xml | 12 +++---
.../disk-floppy-q35.x86_64-latest.xml | 8 ++--
...dev-scsi-autogen-address.x86_64-latest.xml | 6 +--
...tdev-vfio-zpci-boundaries.s390x-latest.xml | 4 +-
...f-aarch64-virt-headless.aarch64-latest.xml | 6 +--
.../hvf-x86_64-q35-headless.x86_64-latest.xml | 6 +--
...ach-virt-console-virtio.aarch64-latest.xml | 6 +--
.../net-isolated-port.x86_64-latest.xml | 12 +++---
.../pci-autoadd-idx.x86_64-latest.xml | 22 +++++------
.../pcie-expander-bus.x86_64-latest.xml | 10 ++---
.../pcie-root.x86_64-latest.xml | 12 +++---
...cie-switch-upstream-port.x86_64-latest.xml | 10 ++---
.../pcihole64-q35.x86_64-latest.xml | 12 +++---
.../pseries-many-buses-2.ppc64-latest.xml | 6 +--
...eries-phb-default-missing.ppc64-latest.xml | 8 ++--
.../qemuxml2xmloutdata/q35.x86_64-latest.xml | 12 +++---
.../riscv64-virt-graphics.riscv64-latest.xml | 6 +--
.../riscv64-virt-headless.riscv64-latest.xml | 6 +--
.../shmem-invalid-size.x86_64-latest.xml | 34 -----------------
.../shmem-small-size.x86_64-latest.xml | 34 -----------------
.../user-aliases2.x86_64-latest.xml | 8 ++--
.../watchdog-q35-multiple.x86_64-latest.xml | 12 +++---
.../x86_64-q35-graphics.x86_64-latest.xml | 6 +--
.../x86_64-q35-headless.x86_64-latest.xml | 6 +--
tests/qemuxmlconftest.c | 38 ++++++++++++++++++-
78 files changed, 405 insertions(+), 404 deletions(-)
delete mode 100644 tests/qemuxml2xmloutdata/shmem-invalid-size.x86_64-latest.xml
delete mode 100644 tests/qemuxml2xmloutdata/shmem-small-size.x86_64-latest.xml
--
2.43.0
9 months, 1 week
[libvirt PATCH 00/12] Add vmx-* features from qemu
by Tim Wiederhake
For rationale, see patch 3 (cpu_map: No longer ignore vmx- features in
sync_qemu_features_i386.py).
Adding features in bunches (one patch per msr index), as this series
is adding ~100 features.
This also adds cpu features "gds-no" and "amx-complex" and brings
libvirt in sync with qemu commit ad6ef0a42e.
Tim Wiederhake (12):
cpu_map: Add missing feature "gds-no"
cpu_map: Add missing feature "amx-complex"
cpu_map: No longer ignore vmx- features in sync_qemu_features_i386.py
cpu_map: Add missing vmx features from MSR 0x480
cpu_map: Add missing vmx features from MSR 0x485
cpu_map: Add missing vmx features from MSR 0x48B
cpu_map: Add missing vmx features from MSR 0x48C
cpu_map: Add missing vmx features from MSR 0x48D
cpu_map: Add missing vmx features from MSR 0x48E
cpu_map: Add missing vmx features from MSR 0x48F
cpu_map: Add missing vmx features from MSR 0x490
cpu_map: Add missing vmx features from MSR 0x491
src/cpu_map/sync_qemu_features_i386.py | 2 +-
src/cpu_map/x86_features.xml | 295 ++++++++++++++++++
.../x86_64-cpuid-Atom-P5362-enabled.xml | 9 +
.../x86_64-cpuid-Atom-P5362-json.xml | 70 +++++
.../x86_64-cpuid-Cooperlake-enabled.xml | 9 +
.../x86_64-cpuid-Cooperlake-json.xml | 71 +++++
.../x86_64-cpuid-Core-i7-8550U-enabled.xml | 9 +
.../x86_64-cpuid-Core-i7-8550U-json.xml | 68 ++++
...86_64-cpuid-Xeon-Platinum-9242-enabled.xml | 9 +
.../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 71 +++++
...-cpuid-baseline-Cooperlake+Cascadelake.xml | 71 +++++
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 68 ++++
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 68 ++++
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 68 ++++
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 68 ++++
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 +
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 +
.../cpu-host-model.x86_64-4.2.0.args | 2 +-
.../cpu-host-model.x86_64-5.0.0.args | 2 +-
.../cpu-host-model.x86_64-latest.args | 2 +-
20 files changed, 960 insertions(+), 4 deletions(-)
--
2.39.2
9 months, 2 weeks
[PATCH 0/5] multiple memory backend support for CPR Live Updates
by mgalaxy＠akamai.com
From: Michael Galaxy <mgalaxy(a)akamai.com>
CPR-based support for whole-hypervisor kexec-based live updates is
making progress on qemu-devel. In support of this, we need NUMA to be
support in these kinds of environments. To do this we use a technology
called PMEM (persistent memory), which underpin the ability for
CPR Live Updates to work so that QEMU memory can remain in RAM and
be recovered after the kexec has completed.
Our systems are highly NUMA-aware, and so this patch series enables
NUMA awareness for live update and also allows live migrations to work.
Further, we make a small change that allows live migrations to work
between *non* PMEM-based systems and PMEM-based systems (and
vice-versa). This allows for seemless upgrades from non-live-compatible
systems to live-update-compatible sytems without any downtime.
Michael Galaxy (5):
qemu.conf changes to support multiple memory backend directories
Update cleanup routines to handle multiple memory backing paths
instead of just one.
Implement multiple memory backing paths
Support live migration between file-backed memory and anonymous
memory.
Update unit test to support multiple memory backends
src/qemu/qemu_command.c | 8 ++-
src/qemu/qemu_conf.c | 140 ++++++++++++++++++++++++++++++++++++----
src/qemu/qemu_conf.h | 14 ++--
src/qemu/qemu_domain.c | 24 +++++--
src/qemu/qemu_driver.c | 31 +++++----
src/qemu/qemu_hotplug.c | 6 +-
src/qemu/qemu_process.c | 45 +++++++------
src/qemu/qemu_process.h | 13 ++--
tests/testutilsqemu.c | 5 +-
9 files changed, 217 insertions(+), 69 deletions(-)
--
2.25.1
9 months, 3 weeks
[PATCH 00/10] Subject: [PATCH 00/10] Code cleanup
by Artem Chernyshev
Several functions was modified to become invariant. Change
their type to void and remove unnecessary checks of their
return values.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Artem Chernyshev (10):
conf: domain_conf: virDomainHostdevInsert/virDomainNetInsert to void
libxl: libxlMakeDomainCapabilities to void
virtime: virTimeMillisNowRaw to void
conf: virDomainGraphicsListenAppendAddress() to void
conf: virDomainDefMaybeAddInput() to void
virbitmap: virBitmapToData() to void
tools: cmdDomblkinfoGet() to void
vireventglib: virEventRunDefaultImpl() to void
vsh: vshCompleterFilter() to void
vsh: vshInitDebug() to void
examples/c/misc/event-test.c | 5 +-
include/libvirt/libvirt-event.h | 2 +-
src/ch/ch_monitor.c | 5 +-
src/conf/domain_conf.c | 35 +++-------
src/conf/domain_conf.h | 8 +--
src/conf/virdomainjob.c | 7 +-
src/hypervisor/domain_driver.c | 5 +-
src/libxl/libxl_capabilities.c | 40 ++++--------
src/libxl/libxl_capabilities.h | 2 +-
src/libxl/libxl_domain.c | 16 ++---
src/libxl/libxl_domain.h | 2 +-
src/libxl/libxl_driver.c | 17 ++---
src/libxl/xen_common.c | 25 +++----
src/libxl/xen_common.h | 2 +-
src/libxl/xen_xl.c | 3 +-
src/lxc/lxc_driver.c | 6 +-
src/nwfilter/nwfilter_dhcpsnoop.c | 18 ++---
src/qemu/qemu_agent.c | 6 +-
src/qemu/qemu_backup.c | 3 +-
src/qemu/qemu_dbus.c | 3 +-
src/qemu/qemu_domain.c | 35 ++++------
src/qemu/qemu_domainjob.c | 22 +++----
src/qemu/qemu_domainjob.h | 4 +-
src/qemu/qemu_driver.c | 19 +++---
src/qemu/qemu_hotplug.c | 6 +-
src/qemu/qemu_migration.c | 4 +-
src/qemu/qemu_nbdkit.c | 3 +-
src/qemu/qemu_process.c | 12 ++--
src/qemu/qemu_tpm.c | 3 +-
src/rpc/virnetdaemon.c | 6 +-
src/storage/storage_backend_iscsi_direct.c | 4 +-
src/util/virbitmap.c | 6 +-
src/util/virbitmap.h | 2 +-
src/util/virevent.c | 7 +-
src/util/vireventglib.c | 4 +-
src/util/vireventglib.h | 2 +-
src/util/virfdstream.c | 3 +-
src/util/virhostcpu.c | 4 +-
src/util/virhostuptime.c | 3 +-
src/util/virtime.c | 48 ++++----------
src/util/virtime.h | 14 ++--
src/vbox/vbox_common.c | 4 +-
src/vmx/vmx.c | 3 +-
src/vz/vz_driver.c | 38 +++++------
src/vz/vz_sdk.c | 14 ++--
src/vz/vz_utils.c | 16 ++---
src/vz/vz_utils.h | 2 +-
tests/domaincapstest.c | 3 +-
tests/objecteventtest.c | 76 ++++++++++------------
tests/qemucapsprobe.c | 5 +-
tests/qemumonitortestutils.c | 8 +--
tests/virbitmaptest.c | 3 +-
tests/virnetsockettest.c | 3 +-
tools/virsh-completer-domain.c | 6 +-
tools/virsh-domain-monitor.c | 10 +--
tools/virsh-domain.c | 15 ++---
tools/vsh.c | 24 +++----
57 files changed, 231 insertions(+), 420 deletions(-)
--
2.43.0
9 months, 4 weeks
[PATCH 0/2] Introduce mshv Hypervisor type.
by Praveen K Paladugu
These patches introduce 'mshv' hypervisor type and check for the hypervisor
device on host while starting ch guests.
Praveen K Paladugu (2):
conf: Introduce mshv hypervisor type
ch: Check for hypervisor while starting guests
src/ch/ch_conf.c | 2 ++
src/ch/ch_driver.c | 7 +++++++
src/ch/ch_process.c | 34 ++++++++++++++++++++++++++++++++++
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_command.c | 1 +
6 files changed, 46 insertions(+)
--
2.43.0
10 months, 1 week
[PATCH 1/3] qemu: add a 'chain' parameter to nbdkit start/stop
by Jonathon Jongsma
This will allow us to start or stop nbdkit for just a single disk source
or for every source in the backing chain. This will be used in following
patches.
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
src/qemu/qemu_extdevice.c | 8 +++---
src/qemu/qemu_hotplug.c | 6 ++---
src/qemu/qemu_nbdkit.c | 51 ++++++++++++++++++++++++++++++---------
src/qemu/qemu_nbdkit.h | 6 +++--
4 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c
index 3cf3867056..ed5976d1f7 100644
--- a/src/qemu/qemu_extdevice.c
+++ b/src/qemu/qemu_extdevice.c
@@ -234,12 +234,12 @@ qemuExtDevicesStart(virQEMUDriver *driver,
for (i = 0; i < def->ndisks; i++) {
virDomainDiskDef *disk = def->disks[i];
- if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0)
return -1;
}
if (def->os.loader && def->os.loader->nvram) {
- if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram, true) < 0)
return -1;
}
@@ -297,11 +297,11 @@ qemuExtDevicesStop(virQEMUDriver *driver,
for (i = 0; i < def->ndisks; i++) {
virDomainDiskDef *disk = def->disks[i];
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
}
if (def->os.loader && def->os.loader->nvram)
- qemuNbdkitStopStorageSource(def->os.loader->nvram, vm);
+ qemuNbdkitStopStorageSource(def->os.loader->nvram, vm, true);
}
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 31b00e05ca..e67673b762 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1018,7 +1018,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver,
if (qemuHotplugAttachManagedPR(vm, disk->src, VIR_ASYNC_JOB_NONE) < 0)
goto cleanup;
- if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0)
+ if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0)
goto cleanup;
}
@@ -1045,7 +1045,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver,
if (virStorageSourceChainHasManagedPR(disk->src))
ignore_value(qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE));
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
}
qemuDomainSecretDiskDestroy(disk);
qemuDomainCleanupStorageSourceFD(disk->src);
@@ -4562,7 +4562,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriver *driver,
qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE) < 0)
goto cleanup;
- qemuNbdkitStopStorageSource(disk->src, vm);
+ qemuNbdkitStopStorageSource(disk->src, vm, true);
if (disk->transient) {
VIR_DEBUG("Removing transient overlay '%s' of disk '%s'",
diff --git a/src/qemu/qemu_nbdkit.c b/src/qemu/qemu_nbdkit.c
index 1c72b6fe6a..39f9c58a48 100644
--- a/src/qemu/qemu_nbdkit.c
+++ b/src/qemu/qemu_nbdkit.c
@@ -893,18 +893,34 @@ qemuNbdkitInitStorageSource(qemuNbdkitCaps *caps WITHOUT_NBDKIT_UNUSED,
}
+static int
+qemuNbdkitStartStorageSourceOne(virQEMUDriver *driver,
+ virDomainObj *vm,
+ virStorageSource *src)
+{
+ qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src);
+
+ if (priv && priv->nbdkitProcess &&
+ qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0)
+ return -1;
+
+ return 0;
+}
+
+
int
qemuNbdkitStartStorageSource(virQEMUDriver *driver,
virDomainObj *vm,
- virStorageSource *src)
+ virStorageSource *src,
+ bool chain)
{
virStorageSource *backing;
- for (backing = src; backing != NULL; backing = backing->backingStore) {
- qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing);
+ if (!chain)
+ return qemuNbdkitStartStorageSourceOne(driver, vm, src);
- if (priv && priv->nbdkitProcess &&
- qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0)
+ for (backing = src; backing != NULL; backing = backing->backingStore) {
+ if (qemuNbdkitStartStorageSourceOne(driver, vm, backing) < 0)
return -1;
}
@@ -912,18 +928,31 @@ qemuNbdkitStartStorageSource(virQEMUDriver *driver,
}
+static void
+qemuNbdkitStopStorageSourceOne(virStorageSource *src,
+ virDomainObj *vm)
+{
+ qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src);
+
+ if (priv && priv->nbdkitProcess &&
+ qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0)
+ VIR_WARN("Unable to stop nbdkit for storage source '%s'",
+ qemuBlockStorageSourceGetStorageNodename(src));
+}
+
+
void
qemuNbdkitStopStorageSource(virStorageSource *src,
- virDomainObj *vm)
+ virDomainObj *vm,
+ bool chain)
{
virStorageSource *backing;
- for (backing = src; backing != NULL; backing = backing->backingStore) {
- qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing);
+ if (! chain)
+ return qemuNbdkitStopStorageSourceOne(src, vm);
- if (priv && priv->nbdkitProcess &&
- qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0)
- VIR_WARN("Unable to stop nbdkit for storage source '%s'", qemuBlockStorageSourceGetStorageNodename(src));
+ for (backing = src; backing != NULL; backing = backing->backingStore) {
+ qemuNbdkitStopStorageSourceOne(backing, vm);
}
}
diff --git a/src/qemu/qemu_nbdkit.h b/src/qemu/qemu_nbdkit.h
index 853b2cca6f..637bf962a7 100644
--- a/src/qemu/qemu_nbdkit.h
+++ b/src/qemu/qemu_nbdkit.h
@@ -63,11 +63,13 @@ qemuNbdkitReconnectStorageSource(virStorageSource *source,
int
qemuNbdkitStartStorageSource(virQEMUDriver *driver,
virDomainObj *vm,
- virStorageSource *src);
+ virStorageSource *src,
+ bool chain);
void
qemuNbdkitStopStorageSource(virStorageSource *src,
- virDomainObj *vm);
+ virDomainObj *vm,
+ bool chain);
int
qemuNbdkitStorageSourceManageProcess(virStorageSource *src,
--
2.43.0
10 months, 2 weeks
[PATCH v2 0/5] Initial network support in ch driver.
by Praveen K Paladugu
v2:
* Refactor virSocketRecvHttpResponse to return responses without parsing http
responses.
* Use errno to report errors in virsocket.c
* Address WIN32 build failure in virsocket.c
* Fix code indentations
Praveen K Paladugu (5):
conf: Drop unused parameter
hypervisor: Move domain interface mgmt methods
util: Add util methods required by ch networking
ch: Introduce version based cap for network support
ch: Enable ETHERNET Network mode support
po/POTFILES | 3 +
src/ch/ch_capabilities.c | 9 +
src/ch/ch_capabilities.h | 1 +
src/ch/ch_conf.h | 4 +
src/ch/ch_domain.c | 41 +++
src/ch/ch_domain.h | 3 +
src/ch/ch_interface.c | 100 +++++++
src/ch/ch_interface.h | 35 +++
src/ch/ch_monitor.c | 213 +++++---------
src/ch/ch_monitor.h | 7 +-
src/ch/ch_process.c | 166 ++++++++++-
src/ch/meson.build | 2 +
src/conf/domain_conf.c | 1 -
src/conf/domain_conf.h | 3 +-
src/hypervisor/domain_interface.c | 457 ++++++++++++++++++++++++++++++
src/hypervisor/domain_interface.h | 45 +++
src/hypervisor/meson.build | 1 +
src/libvirt_private.syms | 11 +
src/libxl/libxl_domain.c | 2 +-
src/libxl/libxl_driver.c | 4 +-
src/lxc/lxc_driver.c | 2 +-
src/lxc/lxc_process.c | 4 +-
src/qemu/qemu_command.c | 8 +-
src/qemu/qemu_hotplug.c | 15 +-
src/qemu/qemu_interface.c | 339 +---------------------
src/qemu/qemu_interface.h | 11 -
src/qemu/qemu_process.c | 72 +----
src/util/virsocket.c | 116 ++++++++
src/util/virsocket.h | 3 +
29 files changed, 1107 insertions(+), 571 deletions(-)
create mode 100644 src/ch/ch_interface.c
create mode 100644 src/ch/ch_interface.h
create mode 100644 src/hypervisor/domain_interface.c
create mode 100644 src/hypervisor/domain_interface.h
--
2.43.0
10 months, 3 weeks