[PATCH v5 00/30] native support for nftables in virtual network driver
by Laine Stump
V4: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HX...
V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HO...
V2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5R...
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).
Changes from V4:
* changed the way that default firewall backends are specified in
meson_options.txt/on the meson commandline - instead of using a
#defined constant string, there are now one of these for each
backend that should be tried when none is specified:
#define FIREWALL_BACKEND_DEFAULT_n VIR_FIREWALL_BACKEND_xyzzy
The "n" will be 1-[number of backends], and the code will try each
in ascending order to see if it is usable.
* properly handle the case where network.conf doesn't exist (from
Patch 12/30 in V3)
* In RPM specfile, Require: nftables for Fedora >= 41 /RHEL >= 10,
while continuining to Require: iptables for anything else
(specifically older RHEL/Fedora)
* use VIR_NFTABLES_FORWARD_CHAIN instead of hardcoded "forward" in
array of chains needed for the nftable backend.
The patches that haven't yet gotten an R-B (and/or were changed enough
from V3 to warrant removing the R-B):
12 - network: support setting firewallBackend from network.conf
17 - util: add name attribute to virFirewall (so that the
element in the status XML is appropriately identifiable)
18 - util: new function virFirewallNewFromRollback()
19 - util: new functions virFirewallParseXML() and virFirewallFormat()
24 - network: add an nftables backend for network driver's firewall construction
26: network: prefer the nftables backend over iptables
(I didn't remove the R-B for patch 27 ("require nftables rather than
iptables for newer RHEl/Fedora") for example, because the change is
very small, and was exactly copy-pasted from Daniel's suggestion).
Changes from V3:
* Fixed a bug (newly added in V3) that resulted in the firewall name
attribute not being added to the XML.
* renamed the table to "libvirt_network"
* renamed the chains to be more descriptive, and lower case rather
than all caps.
* eliminated all the guest->host and host->guest rules since they are
redundant in nftables.
Laine Stump (30):
util/network: move viriptables.[ch] from util to network directory
network: move all functions manipulating iptables rules into
network_iptables.c
network: make all iptables functions used only in network_iptables.c
static
util: #define the names used for private packet filter chains
util: change name of virFirewallRule to virFirewallCmd
util: rename virNetFilterAction to iptablesAction, and add
VIR_ENUM_DECL/IMPL
util: check for 0 args when applying iptables rule
util: add -w/--concurrent when applying a FirewallCmd rather than when
building it
util: determine ignoreErrors value when creating virFirewallCmd, not
when applying
util/network: new virFirewallBackend enum
network: add (empty) network.conf file to distribution files
network: support setting firewallBackend from network.conf
network: framework to call backend-specific function to init private
filter chains
util: new functions to support adding individual firewall rollback
commands
util: implement rollback rule autocreation for iptables commands
network: turn on auto-rollback for the rules added for virtual
networks
util: add name attribute to virFirewall
util: new function virFirewallNewFromRollback()
util: new functions virFirewallParseXML() and virFirewallFormat()
conf: add a virFirewall object to virNetworkObj
network: use previously saved list of firewall removal commands
network: save network status when firewall rules are reloaded
meson: stop looking for iptables/ip6tables/ebtables at build time
network: add an nftables backend for network driver's firewall
construction
tests: test cases for nftables backend
network: prefer the nftables backend over iptables
spec: require nftables rather than iptables for newer RHEL/Fedora
network: name the nftables table "libvirt_network" rather than
"libvirt"
network: rename chains used by network driver nftables backend
network: eliminate pointless host input/output rules from nftables
backend
libvirt.spec.in | 9 +-
meson.build | 12 +-
meson_options.txt | 2 +
po/POTFILES | 3 +-
src/conf/virnetworkobj.c | 41 +
src/conf/virnetworkobj.h | 8 +
src/libvirt_private.syms | 58 +-
src/network/bridge_driver.c | 39 +-
src/network/bridge_driver_conf.c | 86 +-
src/network/bridge_driver_conf.h | 3 +
src/network/bridge_driver_linux.c | 630 +------
src/network/bridge_driver_nop.c | 6 +-
src/network/bridge_driver_platform.h | 6 +-
src/network/libvirtd_network.aug | 39 +
src/network/meson.build | 36 +
src/network/network.conf.in | 28 +
src/network/network_iptables.c | 1677 +++++++++++++++++
src/network/network_iptables.h | 30 +
src/network/network_nftables.c | 968 ++++++++++
src/network/network_nftables.h | 28 +
src/network/test_libvirtd_network.aug.in | 5 +
src/nwfilter/nwfilter_ebiptables_driver.c | 1004 +++++-----
src/util/meson.build | 1 -
src/util/virebtables.c | 36 +-
src/util/virfirewall.c | 820 ++++++--
src/util/virfirewall.h | 87 +-
src/util/viriptables.c | 1072 -----------
src/util/viriptables.h | 155 --
.../{base.args => base.iptables} | 0
tests/networkxml2firewalldata/base.nftables | 256 +++
...-linux.args => nat-default-linux.iptables} | 0
.../nat-default-linux.nftables | 144 ++
...pv6-linux.args => nat-ipv6-linux.iptables} | 0
.../nat-ipv6-linux.nftables | 202 ++
...rgs => nat-ipv6-masquerade-linux.iptables} | 0
.../nat-ipv6-masquerade-linux.nftables | 274 +++
...linux.args => nat-many-ips-linux.iptables} | 0
.../nat-many-ips-linux.nftables | 368 ++++
...-linux.args => nat-no-dhcp-linux.iptables} | 0
.../nat-no-dhcp-linux.nftables | 202 ++
...ftp-linux.args => nat-tftp-linux.iptables} | 0
.../nat-tftp-linux.nftables | 144 ++
...inux.args => route-default-linux.iptables} | 0
.../route-default-linux.nftables | 58 +
tests/networkxml2firewalltest.c | 56 +-
tests/virfirewalltest.c | 424 ++---
46 files changed, 6258 insertions(+), 2759 deletions(-)
create mode 100644 src/network/libvirtd_network.aug
create mode 100644 src/network/network.conf.in
create mode 100644 src/network/network_iptables.c
create mode 100644 src/network/network_iptables.h
create mode 100644 src/network/network_nftables.c
create mode 100644 src/network/network_nftables.h
create mode 100644 src/network/test_libvirtd_network.aug.in
delete mode 100644 src/util/viriptables.c
delete mode 100644 src/util/viriptables.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.45.0
2 days, 1 hour
[PATCH] Сheck snapshot disk is not NULL when searching it in the VM config
by Fima Shevrin
When creating a snapshot of a VM with multiple hard disks,
the snapshot takes into account the presence of all disks
in the system. If, over time, one of the disks is deleted,
the snapshot will continue to store knowledge of the deleted disk.
This results in the fact that at the moment of deleting the snapshot,
at the validation stage, a disk from the snapshot will be searched which
is not in the VM configuration. As a result, vmdisk variable will
be equal to NULL. Dereferencing a null pointer at the time of calling
virStorageSourceIsSameLocation(vmdisk->src, disk->src) will result in SIGSEGV.
Signed-off-by: Fima Shevrin <efim.shevrin(a)virtuozzo.com>
---
src/qemu/qemu_snapshot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
index 09ec959f10..bf93cd485e 100644
--- a/src/qemu/qemu_snapshot.c
+++ b/src/qemu/qemu_snapshot.c
@@ -3806,7 +3806,7 @@ qemuSnapshotDeleteValidate(virDomainObj *vm,
vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name);
disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name);
- if (!virStorageSourceIsSameLocation(vmdisk->src, disk->src)) {
+ if (vmdisk != NULL && !virStorageSourceIsSameLocation(vmdisk->src, disk->src)) {
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("disk image '%1$s' for internal snapshot '%2$s' is not the same as disk image currently used by VM"),
snapDisk->name, snap->def->name);
--
2.34.1
2 days, 2 hours
[PATCH] rpc: avoid leak of GSource in use for interrupting main loop
by Daniel P. Berrangé
We never release the reference on the GSource created for
interrupting the main loop, nor do we remove it from the
main context if our thread is woken up prior to the wakeup
callback firing.
This can result in a leak of GSource objects, along with an
ever growing list of GSources attached to the main context,
which will gradually slow down execution of the loop, as
several operations are O(N) for the number of attached GSource
objects.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/rpc/virnetclient.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c
index 147b0d661a..6d424eb599 100644
--- a/src/rpc/virnetclient.c
+++ b/src/rpc/virnetclient.c
@@ -1946,7 +1946,7 @@ static int virNetClientIO(virNetClient *client,
/* Check to see if another thread is dispatching */
if (client->haveTheBuck) {
/* Force other thread to wakeup from poll */
- GSource *wakeup = g_idle_source_new();
+ g_autoptr(GSource) wakeup = g_idle_source_new();
g_source_set_callback(wakeup, virNetClientIOWakeup, client->eventLoop, NULL);
g_source_attach(wakeup, client->eventCtx);
@@ -1968,6 +1968,7 @@ static int virNetClientIO(virNetClient *client,
return -1;
}
+ g_source_destroy(wakeup);
VIR_DEBUG("Woken up from sleep head=%p call=%p",
client->waitDispatch, thiscall);
/* Three reasons we can be woken up
--
2.43.0
2 days, 4 hours
[RFC PATCH v3 0/6] Added virtio-net RSS with eBPF support.
by Andrew Melnychenko
This series of rfc patches adds support for loading the RSS eBPF
program and passing it to the QEMU.
Comments and suggestions would be useful.
QEMU with vhost may work with RSS through eBPF. To load eBPF,
the capabilities required that Libvirt may provide.
eBPF program and maps may be unique for particular QEMU and
Libvirt retrieves eBPF through qapi.
For now, there is only "RSS" eBPF object in QEMU, in the future,
there may be another one(g.e. network filters).
That's why in Libvirt added logic to load and store any
eBPF object that QEMU provides using qapi schema.
One of the reasons why this series of patches is in RFC are tests.
To this series of patches, the tests were added.
For now, the tests are synthetic, the proper "reply" file should
be generated with a new "caps" file. Currently, there are changes
in caps-9.0.0* files. There was added support for ebpf_rss_fds feature,
and request-ebpf command.
Also, there was added new config for qemuConfig - allowEBPF.
This config allows to enable/disable eBPF blob loading explicitly.
This is required for qemuxmlconf tests - where some test expects that
RSS would not support eBPF.
So, overall, the tests are required for review, comment, and discussion
how we want them to be implemented in the future.
For virtio-net RSS, the document has not changed.
```
<interface type="network">
<model type="virtio"/>
<driver queues="4" rss="on" rss_hash_report="off"/>
<interface type="network">
```
Simplified routine for RSS:
* Libvirt retrieves eBPF "RSS" and load it.
* Libvirt passes file descriptors to virtio-net with property "ebpf_rss_fds" ("rss" property should be "on" too).
* if fds was provided - QEMU using eBPF RSS implementation.
* if fds was not provided - QEMU tries to load eBPF RSS in own context and use it.
* if eBPF RSS was not loaded - QEMU uses "in-qemu" RSS(vhost not supported).
Changes since RFC v2:
* refactored and rebased.
* applied changes according to the Qemu.
* added basic test.
Changes since RFC v1:
* changed eBPF format saved in the XML cache.
* refactored and checked with syntax test.
* refactored patch hunks.
Andrew Melnychenko (6):
qemu_monitor: Added QEMU's "request-ebpf" support.
qemu_capabilities: Added logic for retrieving eBPF objects from QEMU.
qemu_interface: Added routine for loading the eBPF objects.
qemu_command: Added "ebpf_rss_fds" support for virtio-net.
qemu_conf: Added configuration to optionally disable eBPF loading.
tests: Added tests for eBPF blob loading.
meson.build | 7 +
meson_options.txt | 1 +
src/qemu/meson.build | 1 +
src/qemu/qemu_capabilities.c | 126 +++++++++++
src/qemu/qemu_capabilities.h | 6 +
src/qemu/qemu_command.c | 63 ++++++
src/qemu/qemu_conf.c | 2 +
src/qemu/qemu_conf.h | 2 +
src/qemu/qemu_domain.c | 4 +
src/qemu/qemu_domain.h | 3 +
src/qemu/qemu_interface.c | 83 ++++++++
src/qemu/qemu_interface.h | 4 +
src/qemu/qemu_monitor.c | 13 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 26 +++
src/qemu/qemu_monitor_json.h | 3 +
.../caps_9.0.0_x86_64.replies | 199 ++++++++++--------
.../caps_9.0.0_x86_64.xml | 4 +
tests/qemuxml2argvmock.c | 21 ++
.../net-virtio-rss-bpf.x86_64-latest.args | 37 ++++
.../net-virtio-rss-bpf.x86_64-latest.xml | 46 ++++
tests/qemuxmlconfdata/net-virtio-rss-bpf.xml | 46 ++++
tests/qemuxmlconftest.c | 4 +
23 files changed, 612 insertions(+), 92 deletions(-)
create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.xml
--
2.44.0
2 days, 5 hours
[PATCH] qemu: fix qemu command for pci hostdevs and ramfb='off'
by Jonathon Jongsma
There was no test for this and we mistakenly used 'B' rather than 'T'
when constructing the json value for this parameter. Thus, a value of
'off' was VIR_TRISTATE_SWITCH_OFF=2, which was translated to a boolean
value of 'true'.
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
src/qemu/qemu_command.c | 2 +-
.../hostdev-pci-display-ramfb.x86_64-latest.args | 1 +
.../hostdev-pci-display-ramfb.x86_64-latest.xml | 6 ++++++
tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml | 5 +++++
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 63bfeb790e..2d0eddc79e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4798,7 +4798,7 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
"p:bootindex", dev->info->effectiveBootIndex,
"S:failover_pair_id", failover_pair_id,
"S:display", qemuOnOffAuto(pcisrc->display),
- "B:ramfb", pcisrc->ramfb,
+ "T:ramfb", pcisrc->ramfb,
NULL) < 0)
return NULL;
diff --git a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args
index 6a3bfbe6fb..e6e538ef1c 100644
--- a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args
+++ b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args
@@ -29,5 +29,6 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest2/.config \
-audiodev '{"id":"audio1","driver":"none"}' \
-vnc 127.0.0.1:0,audiodev=audio1 \
-device '{"driver":"vfio-pci-nohotplug","host":"0000:06:12.5","id":"hostdev0","display":"on","ramfb":true,"bus":"pci.0","addr":"0x2"}' \
+-device '{"driver":"vfio-pci","host":"0000:06:13.6","id":"hostdev1","display":"off","ramfb":false,"bus":"pci.0","addr":"0x3"}' \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
diff --git a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.xml b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.xml
index 16e8a1dee2..18b9bfb5bf 100644
--- a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.xml
+++ b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.xml
@@ -39,6 +39,12 @@
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</hostdev>
+ <hostdev mode='subsystem' type='pci' managed='no' display='off' ramfb='off'>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x13' function='0x6'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+ </hostdev>
<memballoon model='none'/>
</devices>
</domain>
diff --git a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml
index 39c84da7e1..d263342b1d 100644
--- a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml
+++ b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml
@@ -25,6 +25,11 @@
<address domain='0x0000' bus='0x06' slot='0x12' function='0x5'/>
</source>
</hostdev>
+ <hostdev mode='subsystem' type='pci' display='off' ramfb='off'>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x13' function='0x6'/>
+ </source>
+ </hostdev>
<video>
<model type='none'/>
</video>
--
2.45.0
2 days, 10 hours
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
by Michael Galaxy
These are very compelling results, no?
(40gbps cards, right? Are the cards active/active? or active/standby?)
- Michael
On 5/14/24 10:19, Yu Zhang wrote:
> Hello Peter and all,
>
> I did a comparison of the VM live-migration speeds between RDMA and
> TCP/IP on our servers
> and plotted the results to get an initial impression. Unfortunately,
> the Ethernet NICs are not the
> recent ones, therefore, it may not make much sense. I can do it on
> servers with more recent Ethernet
> NICs and keep you updated.
>
> It seems that the benefits of RDMA becomes obviously when the VM has
> large memory and is
> running memory-intensive workload.
>
> Best regards,
> Yu Zhang @ IONOS Cloud
>
> On Thu, May 9, 2024 at 4:14 PM Peter Xu <peterx(a)redhat.com> wrote:
>> On Thu, May 09, 2024 at 04:58:34PM +0800, Zheng Chuan via wrote:
>>> That's a good news to see the socket abstraction for RDMA!
>>> When I was developed the series above, the most pain is the RDMA migration has no QIOChannel abstraction and i need to take a 'fake channel'
>>> for it which is awkward in code implementation.
>>> So, as far as I know, we can do this by
>>> i. the first thing is that we need to evaluate the rsocket is good enough to satisfy our QIOChannel fundamental abstraction
>>> ii. if it works right, then we will continue to see if it can give us opportunity to hide the detail of rdma protocol
>>> into rsocket by remove most of code in rdma.c and also some hack in migration main process.
>>> iii. implement the advanced features like multi-fd and multi-uri for rdma migration.
>>>
>>> Since I am not familiar with rsocket, I need some times to look at it and do some quick verify with rdma migration based on rsocket.
>>> But, yes, I am willing to involved in this refactor work and to see if we can make this migration feature more better:）
>> Based on what we have now, it looks like we'd better halt the deprecation
>> process a bit, so I think we shouldn't need to rush it at least in 9.1
>> then, and we'll need to see how it goes on the refactoring.
>>
>> It'll be perfect if rsocket works, otherwise supporting multifd with little
>> overhead / exported APIs would also be a good thing in general with
>> whatever approach. And obviously all based on the facts that we can get
>> resources from companies to support this feature first.
>>
>> Note that so far nobody yet compared with rdma v.s. nic perf, so I hope if
>> any of us can provide some test results please do so. Many people are
>> saying RDMA is better, but I yet didn't see any numbers comparing it with
>> modern TCP networks. I don't want to have old impressions floating around
>> even if things might have changed.. When we have consolidated results, we
>> should share them out and also reflect that in QEMU's migration docs when a
>> rdma document page is ready.
>>
>> Chuan, please check the whole thread discussion, it may help to understand
>> what we are looking for on rdma migrations [1]. Meanwhile please feel free
>> to sync with Jinpu's team and see how to move forward with such a project.
>>
>> [1] https://urldefense.com/v3/__https://lore.kernel.org/qemu-devel/87frwatp7n...
>>
>> Thanks,
>>
>> --
>> Peter Xu
>>
3 days, 1 hour
[PATCH 0/2] Add support for hotplugging evdev input devices
by Rayhan Faizel
This patch series extends the current evdev device implementation to allow
hotplugging, including live attachment and detachment.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/529
Rayhan Faizel (2):
qemu: Implement support for hotplugging evdev input devices
qemuhotplugtest: Add testcases for hotplugging evdev input devices
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_command.h | 3 +
src/qemu/qemu_hotplug.c | 95 +++++++++++++------
tests/qemuhotplugtest.c | 5 +
.../qemuhotplug-input-evdev.xml | 3 +
.../qemuhotplug-base-live+input-evdev.xml | 58 +++++++++++
6 files changed, 137 insertions(+), 29 deletions(-)
create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-input-evdev.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+input-evdev.xml
--
2.34.1
3 days, 6 hours
[PATCH 0/2] Make affinity setting a bit more debug friendly
by Michal Privoznik
*** 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 days, 6 hours
[PATCH 0/2] hw/core: revert deprecation of 'parameter=1' for SMP topology
by Daniel P. Berrangé
Since QEMU 9.0, users are complaining that depecation messages are shown
for every VM libvirt starts. This is due to the newly introduced
deprecation of 'parameter=1' for -smp. This proposes reverting that, see
the 1st patch for further commentary.
Daniel P. Berrangé (2):
hw/core: allow parameter=1 for CPU topology on any machine
tests: add testing of parameter=1 for SMP topology
docs/about/deprecated.rst | 14 -------
hw/core/machine-smp.c | 82 ++++++++++++-------------------------
tests/unit/test-smp-parse.c | 16 ++++++--
3 files changed, 38 insertions(+), 74 deletions(-)
--
2.43.0
4 days, 2 hours
