[PATCH v2 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober
Similar to the qemu.conf file that allows QEMU specific configurations we add
the possibility to specify a ch.conf file for Cloud Hypervisor configuration.
The initial single config option is the log level, which sets the verbosity of
the Cloud Hypervisor process. This allows for simpler debugging when using
Cloud Hypervisor via libvirt.
Stefan Kober (3):
ch: Add config file support
ch: add log level configuration option
NEWS: ch: announce log_level config option
NEWS.rst | 5 +++++
src/ch/ch.conf | 11 ++++++++++
src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++
src/ch/ch_conf.h | 18 +++++++++++++++
src/ch/ch_driver.c | 6 +++++
src/ch/ch_monitor.c | 6 +++++
src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++
src/ch/meson.build | 12 ++++++++++
src/ch/test_libvirtd_ch.aug.in | 5 +++++
9 files changed, 134 insertions(+)
create mode 100644 src/ch/ch.conf
create mode 100644 src/ch/libvirtd_ch.aug
create mode 100644 src/ch/test_libvirtd_ch.aug.in
--
2.49.0
3 days, 1 hour
[PATCH v3 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v3
- added qemu caps check to avoid breaking s390 guests trying to
default deprecated_features='off' on QEMU versions that
do not support reporting these features
v2
- changed behavior from disabling features on the host model to
instead flagging the guest CPU to disable deprecated features
- removed disabling deprecated features on host model in
virQEMUCapsInitCPUModelS390
- added flagging deprecated_feats in qemuProcessUpdateGuestCPU
- added tests for deprecated_features='on'
- split virQEMUCapsUpdateCPUDeprecatedFeatures update and
qemuProcessUpdateGuestCPU changes
The intention of reporting deprecated features and modifying the guest
CPU model was to alleviate the user from the burden of preparing a guest
with the necessary amendments to assure migration to newer hardware.
While that goal was met by way of the "deprecated_features='on|off'"
attribute, it still adds an extra step that the user must be aware to
prepare a guest for migration and the errors that stem from an
unsuccessful migration (due to feature incompatibility) is not always
clear how to resolve.
These patches make s390 CPU host models migration ready from the get-go
by disabling deprecated features by default. They may still be disabled
for other model types via the respective attribute, or reenabled if
desired.
Collin Walling (3):
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
qemu: process: disable deprecated features for s390 models by default
src/qemu/qemu_capabilities.c | 6 ++--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 32 ++++++++++++++-----
...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++
...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++
.../cpu-model-deprecated-features-on.xml | 15 +++++++++
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 1 +
14 files changed, 110 insertions(+), 19 deletions(-)
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml
--
2.47.1
3 days, 17 hours
[PATCH 0/4] qemu: Reflect support of floppy devices in capabilities XML
by Peter Krempa
Probe if qemu actually supports floppy controllers which can be compiled
out with custom configs and reflect that in the capability XML.
Peter Krempa (4):
qemu: domain: Introduce qemuDomainMachineSupportsFloppy
qemu: Move floppy device support validation to validation code
qemu: capabilities: Introduce QEMU_CAPS_BUS_FLOPPY
qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY
src/qemu/qemu_capabilities.c | 6 ++-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_domain.c | 15 +++++++
src/qemu/qemu_domain.h | 4 ++
src/qemu/qemu_process.c | 8 ----
src/qemu/qemu_validate.c | 7 +++
.../qemu_10.0.0-virt.aarch64.xml | 2 -
tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 -
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 2 -
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 2 -
.../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 -
.../qemu_8.2.0-virt.aarch64.xml | 2 -
.../qemu_8.2.0-virt.loongarch64.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.s390x.xml | 2 -
.../qemu_9.1.0-tcg-virt.riscv64.xml | 2 -
.../qemu_9.1.0-virt.riscv64.xml | 2 -
tests/domaincapsdata/qemu_9.1.0.s390x.xml | 2 -
.../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 -
tests/domaincapsdata/qemu_9.2.0.s390x.xml | 2 -
.../caps_10.0.0_ppc64.xml | 1 +
.../caps_10.0.0_x86_64+amdsev.xml | 1 +
.../caps_10.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 +
.../caps_6.2.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 +
.../caps_7.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 +
.../caps_7.1.0_x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 +
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_x86_64.xml | 1 +
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 1 +
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_x86_64.xml | 1 +
.../caps_9.2.0_x86_64+amdsev.xml | 1 +
.../caps_9.2.0_x86_64.xml | 1 +
.../disk-floppy-pseries.ppc64-latest.err | 2 +-
.../disk-floppy-pseries.ppc64-latest.xml | 44 -------------------
tests/qemuxmlconftest.c | 2 +-
44 files changed, 53 insertions(+), 86 deletions(-)
delete mode 100644 tests/qemuxmlconfdata/disk-floppy-pseries.ppc64-latest.xml
--
2.49.0
3 days, 19 hours
[PATCH 0/2] network: support NAT networking for FreeBSD/pf
by Roman Bogorodskiy
This series implements NAT networks support for FreeBSD using the Packet
Filter (pf) firewall.
The commit messages provide high-level details and limitations of the
current implementation, and I'll use this cover letter to provide some
more technical details and describe testing I have performed for this
change.
Libvirt FreeBSD/pf NAT testing
For two networks:
virsh # net-dumpxml default
<network>
<name>default</name>
<uuid>68cd5419-9fda-4cf0-9ac6-2eb9c1ba41ed</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:db:0e:e5'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
virsh # net-dumpxml natnet
<network>
<name>natnet</name>
<uuid>d3c59659-3ceb-4482-a625-1f839a54429c</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='52:54:00:0a:fc:1d'/>
<ip address='10.0.100.1' netmask='255.255.255.0'>
<dhcp>
<range start='10.0.100.2' end='10.0.100.254'/>
</dhcp>
</ip>
</network>
virsh #
The following rules are generated:
$ sudo pfctl -a '*' -sn
nat-anchor "libvirt/*" all {
nat-anchor "default" all {
nat pass on re0 inet from 192.168.122.0/24 to <natdst> -> (re0) port
1024:65535 round-robin
}
nat-anchor "natnet" all {
nat pass on re0 inet from 10.0.100.0/24 to <natdst> -> (re0) port
1024:65535 round-robin
}
}
$
$ sudo pfctl -a 'libvirt/default' -t natdst -T show
0.0.0.0/0
!192.168.122.0/24
!224.0.0.0/24
!255.255.255.255
$ sudo pfctl -a 'libvirt/natnet' -t natdst -T show
0.0.0.0/0
!10.0.100.0/24
!224.0.0.0/24
!255.255.255.255
$
$ sudo pfctl -a '*' -sr
scrub all fragment reassemble
anchor "libvirt/*" all {
anchor "default" all {
pass quick on virbr0 inet from 192.168.122.0/24 to 192.168.122.0/24
flags S/SA keep state
pass quick on virbr0 inet from 192.168.122.0/24 to 224.0.0.0/24
flags S/SA keep state
pass quick on virbr0 inet from 192.168.122.0/24 to 255.255.255.255
flags S/SA keep state
block drop on virbr0 all
}
anchor "natnet" all {
pass quick on virbr1 inet from 10.0.100.0/24 to 10.0.100.0/24 flags
S/SA keep state
pass quick on virbr1 inet from 10.0.100.0/24 to 224.0.0.0/24 flags
S/SA keep state
pass quick on virbr1 inet from 10.0.100.0/24 to 255.255.255.255
flags S/SA keep state
block drop on virbr1 all
}
}
pass all flags S/SA keep state
$
Create two guests attached to the "default" network, vmA and vmB.
vmA $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:67:eb:de brd ff:ff:ff:ff:ff:ff
inet 192.168.122.92/24 brd 192.168.122.255 scope global dynamic noprefixroute enp0s4
valid_lft 1082sec preferred_lft 1082sec
inet6 fe80::5054:ff:fe67:ebde/64 scope link noprefixroute
valid_lft forever preferred_lft forever
vmA $
vmB $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:d2:8b:41 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.154/24 metric 100 brd 192.168.122.255 scope global dynamic enp0s4
valid_lft 1040sec preferred_lft 1040sec
inet6 fe80::5054:ff:fed2:8b41/64 scope link
valid_lft forever preferred_lft forever
vmB $
Test NAT rules:
vmA $ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=14.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=10.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.1 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 10.099/11.835/14.710/2.047 ms
vmA $
vmB $ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.4 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 10.434/12.198/15.113/2.075 ms
vmB $
vmA $ curl wttr.in/?0Q
Fog
_ - _ - _ - +4(1) °C
_ - _ - _ ↙ 11 km/h
_ - _ - _ - 0 km
0.0 mm
vmA $
vmB $ curl wttr.in/?0Q
Fog
_ - _ - _ - +4(1) °C
_ - _ - _ ↙ 11 km/h
_ - _ - _ - 0 km
0.0 mm
vmB $
Inter-VM connectivity:
vmA $ ping -c 3 192.168.122.154
PING 192.168.122.154 (192.168.122.154) 56(84) bytes of data.
64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.253 ms
64 bytes from 192.168.122.154: icmp_seq=2 ttl=64 time=0.226 ms
64 bytes from 192.168.122.154: icmp_seq=3 ttl=64 time=0.269 ms
--- 192.168.122.154 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2042ms
rtt min/avg/max/mdev = 0.226/0.249/0.269/0.017 ms
vmA $
vmA $ ssh 192.168.122.154 uname
novel(a)192.168.122.154's password:
Linux
vmA $
Multicast test:
vmA $ iperf -s -u -B 224.0.0.1 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Joining multicast group 224.0.0.1
Server set to single client traffic mode (per multicast receive)
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 1] local 224.0.0.1 port 5001 connected with 192.168.122.154 port
36963
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams
[ 1] 0.00-1.00 sec 131 KBytes 1.07 Mbits/sec 0.030 ms 0/91 (0%)
[ 1] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.022 ms 0/89 (0%)
[ 1] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.021 ms 0/89 (0%)
[ 1] 0.00-3.02 sec 389 KBytes 1.06 Mbits/sec 0.026 ms 0/271 (0%)
vmB $ iperf -c 224.0.0.1 -u -T 32 -t 3 -i 1
------------------------------------------------------------
Client connecting to 224.0.0.1, UDP port 5001
Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust)
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.122.154 port 36963 connected with 224.0.0.1 port
5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-1.0000 sec 131 KBytes 1.07 Mbits/sec
[ 1] 1.0000-2.0000 sec 128 KBytes 1.05 Mbits/sec
[ 1] 2.0000-3.0000 sec 128 KBytes 1.05 Mbits/sec
[ 1] 0.0000-3.0173 sec 389 KBytes 1.06 Mbits/sec
[ 1] Sent 272 datagrams
vmB $
Broadcast test:
vmA $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0
vmA $
vmB $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0
vmB $
host $ ping 192.168.122.255
PING 192.168.122.255 (192.168.122.255): 56 data bytes
64 bytes from 192.168.122.154: icmp_seq=0 ttl=64 time=0.199 ms
64 bytes from 192.168.122.92: icmp_seq=0 ttl=64 time=0.227 ms (DUP!)
64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.209 ms
64 bytes from 192.168.122.92: icmp_seq=1 ttl=64 time=0.235 ms (DUP!)
^C
--- 192.168.122.255 ping statistics ---
2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet
loss
round-trip min/avg/max/stddev = 0.199/0.218/0.235/0.014 ms
This testing does not cover any negative scenarios which are probably
not that important at this point.
Roman Bogorodskiy (2):
network: bridge_driver: add BSD implementation
network: introduce Packet Filter firewall backend
meson.build | 2 +
po/POTFILES | 2 +
src/network/bridge_driver_bsd.c | 107 +++++++++
src/network/bridge_driver_conf.c | 8 +
src/network/bridge_driver_linux.c | 2 +
src/network/bridge_driver_platform.c | 2 +
src/network/meson.build | 1 +
src/network/network_pf.c | 327 +++++++++++++++++++++++++++
src/network/network_pf.h | 26 +++
src/util/virfirewall.c | 4 +-
src/util/virfirewall.h | 2 +
11 files changed, 482 insertions(+), 1 deletion(-)
create mode 100644 src/network/bridge_driver_bsd.c
create mode 100644 src/network/network_pf.c
create mode 100644 src/network/network_pf.h
--
2.49.0
3 days, 22 hours
[RFC PATCH 0/2] schemas: path types refactor
by Kirill Shchetiniuk
This series of patches aims to introduce unification for path attributes
in schema definitions. Previously defined types used for schema definitions
are now unified into two main types: absolutePath and relativePath.
This change addresses previous inconsistencies where types were sometimes
used incorrectly (e.g., filePath for directory attributes).
Due to prior inconsistencies, some locations now accept relative paths
even if they were not explicitly intended to. To avoid such inconsistencies
in the future, better names for the path types have been selected.
Moreover, I suggest deprecating (with future patches) the use of relative paths
in places where they are not explicitly meant to be used. This will make the
schemas more consistent and, as a result, encourage users to write more
deterministic XML definitions. For now the relativePath is used in such places
to remain backward compatibility.
Kirill Shchetiniuk (2):
schemas: path types unification / refactor
schemas: path attributes type refactor
src/conf/schemas/basictypes.rng | 18 +---
src/conf/schemas/capability.rng | 4 +-
src/conf/schemas/domainbackup.rng | 10 +-
src/conf/schemas/domaincaps.rng | 2 +-
src/conf/schemas/domaincheckpoint.rng | 2 +-
src/conf/schemas/domaincommon.rng | 132 +++++++++++++-------------
src/conf/schemas/domainsnapshot.rng | 8 +-
src/conf/schemas/network.rng | 4 +-
src/conf/schemas/nodedev.rng | 4 +-
src/conf/schemas/secret.rng | 2 +-
src/conf/schemas/storagecommon.rng | 2 +-
src/conf/schemas/storagepool.rng | 10 +-
src/conf/schemas/storagevol.rng | 6 +-
13 files changed, 96 insertions(+), 108 deletions(-)
--
2.49.0
3 days, 23 hours
[PATCH 0/2] CH: Add support for a configuration file and log level configuration
by Stefan Kober
Similar to the qemu.conf file that allows QEMU specific configurations we add
the possibility to specify a ch.conf file for Cloud Hypervisor configuration.
The initial single config option is the log level, which sets the verbosity of
the Cloud Hypervisor process. This allows for simpler debugging when using
Cloud Hypervisor via libvirt.
Stefan Kober (2):
ch: Add config file support
ch: add log level configuration option
src/ch/ch_conf.c | 32 ++++++++++++++++++++++++++++++++
src/ch/ch_conf.h | 18 ++++++++++++++++++
src/ch/ch_driver.c | 6 ++++++
src/ch/ch_monitor.c | 6 ++++++
4 files changed, 62 insertions(+)
--
2.49.0
4 days, 1 hour
[PATCH v2 0/4] domain_capabilities: add console capabilities
by Roman Bogorodskiy
Main change since v1 is adding console capabilities reporting for the
libxl driver.
There's also a minor cosmetic change in the qemu part to alphabetically
sort VIR_DOMAIN_CHR_TYPE_* arguments for VIR_DOMAIN_CAPS_ENUM_SET().
Apparently, the only other driver reporting domain capabilities is the
test driver, so it looks like all drivers are covered by this series.
Roman Bogorodskiy (4):
domain_capabilities: add console capabilities
bhyve: capabilities: report NMDM console
qemu: capabilities: report supported console types
libxl: capabilities: report supported console types
src/bhyve/bhyve_capabilities.c | 5 +++
src/conf/domain_capabilities.c | 12 +++++++
src/conf/domain_capabilities.h | 8 +++++
src/conf/schemas/domaincaps.rng | 10 ++++++
src/libxl/libxl_capabilities.c | 23 ++++++++++++-
src/qemu/qemu_capabilities.c | 32 +++++++++++++++++++
src/qemu/qemu_capabilities.h | 3 ++
tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +++
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +++
tests/domaincapsdata/bhyve_uefi.x86_64.xml | 5 +++
tests/domaincapsdata/libxl-xenfv.xml | 13 ++++++++
tests/domaincapsdata/libxl-xenpv.xml | 13 ++++++++
.../qemu_10.0.0-q35.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_10.0.0-tcg.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_10.0.0-virt.aarch64.xml | 15 +++++++++
tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 15 +++++++++
tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 15 +++++++++
.../qemu_10.0.0.x86_64+amdsev.xml | 18 +++++++++++
tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 15 +++++++++
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 18 +++++++++++
.../qemu_7.2.0-hvf.x86_64+hvf.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.2.0.ppc.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_8.2.0-tcg-virt.loongarch64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_8.2.0-virt.aarch64.xml | 16 ++++++++++
.../qemu_8.2.0-virt.loongarch64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.2.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.0.0.sparc.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_9.1.0-tcg-virt.riscv64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_9.1.0-virt.riscv64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.1.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 18 +++++++++++
.../qemu_9.2.0-hvf.aarch64+hvf.xml | 16 ++++++++++
.../qemu_9.2.0-q35.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_9.2.0-tcg.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.2.0.s390x.xml | 15 +++++++++
.../qemu_9.2.0.x86_64+amdsev.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 18 +++++++++++
74 files changed, 1213 insertions(+), 1 deletion(-)
--
2.49.0
4 days, 2 hours
[PATCH v3 0/2] Fix virtio console port assignment issue
by Aaron M. Brown
Changelog:
---
v3:
- Added Reviewed-By
- Included CI Results Link
---
v2:
- Split patch into two commits
- Added fixes tag
---
This libvirt patch does the following:
1. fixes an issue with virtio console device port assignment on vioserial buses
2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity
Currently in libvirt, a virtio console device cannot be assigned a port number greater than zero on a vioserial bus. This leads to port collision errors when adding more than 1 virtio console device on a single vioserial bus.
After applying this patch, one can add multiple console ports under a single vioserial bus.
Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1831901334
Aaron M. Brown (2):
Fix virtio console port assignment on vioserial bus
Updates console port reservation comment and changes the allowZero
variable to allowPortZero for clarity
src/conf/domain_addr.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
--
2.39.5 (Apple Git-154)
1 week
[PATCH 0/7] nss: Couple of fixes and small improvements
by Michal Privoznik
I've noticed most of these after I've turned on debugging for the NSS
plugin:
diff --git i/tools/nss/libvirt_nss.h w/tools/nss/libvirt_nss.h
index 54a0216013..f9c3136985 100644
--- i/tools/nss/libvirt_nss.h
+++ w/tools/nss/libvirt_nss.h
@@ -35 +35 @@
-#if 0
+#if 1
Michal Prívozník (7):
libvirt_nss_macs: Fix type of @len in findMACsFromJSON()
nss: Add missing includes for gai_strerror()
nss: Declare g_autofree and g_steal_pointer() macros
libvirt_nss: Use automatic memory freeing
libvirt_nss: Drop needless cleanup labels
libvirt_nss: Allocate buffer in ERROR() dynamically
libvirt_nss: Allocate buffer in aiforaf() dynamically
build-aux/syntax-check.mk | 2 +-
tools/nss/libvirt_nss.c | 52 +++++++++++++---------------------
tools/nss/libvirt_nss.h | 33 +++++++++++++++++++--
tools/nss/libvirt_nss_leases.c | 3 ++
tools/nss/libvirt_nss_macs.c | 2 +-
5 files changed, 55 insertions(+), 37 deletions(-)
--
2.49.0
1 week
[PATCH] virsh: Do not print warnings with "error:" prefix
by Jiri Denemark
From: Jiri Denemark <jdenemar(a)redhat.com>
Both vshWarn and vshError are just wrappers around vshPrintStderr which
properly propagates the message level to the log, but fails to honor it
when printing on stderr.
https://issues.redhat.com/browse/RHEL-79460
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tools/vsh.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/vsh.c b/tools/vsh.c
index 05845e2c1e..e892cbca22 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -2123,7 +2123,11 @@ vshPrintStderr(vshControl *ctl,
* printing to stderr will not interleave correctly with stdout
* unless we flush between every transition between streams. */
fflush(stdout);
- fprintf(stderr, _("error: %1$s\n"), NULLSTR(str));
+
+ if (level == VSH_ERR_WARNING)
+ fprintf(stderr, _("warning: %1$s\n"), NULLSTR(str));
+ else
+ fprintf(stderr, _("error: %1$s\n"), NULLSTR(str));
fflush(stderr);
}
--
2.49.0
1 week
