September 2024 - Devel - libvirt List Archives

[PATCH 0/2] qemu: Provide sane default for dump_guest_core
by Michal Privoznik 19 Sep '24

19 Sep '24

*** BLURB HERE *** Michal Prívozník (2): qemu.conf.in: Fix dumpCore capitalization qemu: Provide sane default for dump_guest_core meson.build | 1 + src/qemu/qemu.conf.in | 4 ++-- src/qemu/qemu_conf.c | 11 +++++++++++ tests/testutilsqemu.c | 2 ++ 4 files changed, 16 insertions(+), 2 deletions(-) -- 2.44.2

2 3

[PULL 02/18] deprecation: don't enable TCG plugins by default with TCI
by Alex Bennée 18 Sep '24

18 Sep '24

The softmmu memory instrumentation test sees so many more accesses than a normal translated host and its really not worth fixing up. Lets deprecate this odd configuration and save on the CI cycles. Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240916085400.1046925-3-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 809b2b9b81..c0aa52def5 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -196,6 +196,14 @@ benefits from having plenty of host memory it seems reasonable to encourage users to use 64 bit builds of QEMU for analysis work whatever targets they are instrumenting. +TCG Plugin support not enabled by default with TCI (since 9.2) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +While the TCG interpreter can interpret the TCG ops used by plugins it +is going to be so much slower it wouldn't make sense for any serious +instrumentation. Due to implementation differences there will also be +anomalies in things like memory instrumentation. + System emulator CPUs -------------------- diff --git a/configure b/configure index cc8e1ed5b8..aa7aae70fa 100755 --- a/configure +++ b/configure @@ -629,6 +629,9 @@ meson_option_parse() { exit 1 fi } +has_meson_option() { + test "${meson_options#*"$1"}" != "$meson_options" +} meson_add_machine_file() { if test "$cross_compile" = "yes"; then @@ -1048,8 +1051,12 @@ if test "$static" = "yes" ; then plugins="no" fi if test "$plugins" != "no" && test $host_bits -eq 64; then - plugins=yes - subdirs="$subdirs contrib/plugins" + if has_meson_option "-Dtcg_interpreter=true"; then + plugins="no" + else + plugins=yes + subdirs="$subdirs contrib/plugins" + fi fi cat > $TMPC << EOF -- 2.39.5

1 0

[PULL 01/18] deprecation: don't enable TCG plugins by default on 32 bit hosts
by Alex Bennée 18 Sep '24

18 Sep '24

The existing plugins already liberally use host pointer stuffing for passing user data which will fail when doing 64 bit guests on 32 bit hosts. We should discourage this by officially deprecating support and adding another nail to the 32 bit host coffin. Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240916085400.1046925-2-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ed31d4b0b2..809b2b9b81 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -184,6 +184,17 @@ be an effective use of its limited resources, and thus intends to discontinue it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead. +TCG Plugin support not enabled by default on 32-bit hosts (since 9.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +While it is still possible to enable TCG plugin support for 32-bit +hosts there are a number of potential pitfalls when instrumenting +64-bit guests. The plugin APIs typically pass most addresses as +uint64_t but practices like encoding that address in a host pointer +for passing as user-data will lose data. As most software analysis +benefits from having plenty of host memory it seems reasonable to +encourage users to use 64 bit builds of QEMU for analysis work +whatever targets they are instrumenting. System emulator CPUs -------------------- diff --git a/configure b/configure index f3e7572afb..cc8e1ed5b8 100755 --- a/configure +++ b/configure @@ -516,6 +516,25 @@ case "$cpu" in ;; esac +# Now we have our CPU_CFLAGS we can check if we are targeting a 32 or +# 64 bit host. + +check_64bit_host() { +cat > $TMPC <<EOF +#if __SIZEOF_POINTER__ != 8 +#error not 64 bit system +#endif +int main(void) { return 0; } +EOF + compile_object "$1" +} + +if check_64bit_host "$CPU_CFLAGS"; then + host_bits=64 +else + host_bits=32 +fi + if test -n "$host_arch" && { ! test -d "$source_path/linux-user/include/host/$host_arch" || ! test -d "$source_path/common-user/host/$host_arch"; }; then @@ -1028,7 +1047,7 @@ if test "$static" = "yes" ; then fi plugins="no" fi -if test "$plugins" != "no"; then +if test "$plugins" != "no" && test $host_bits -eq 64; then plugins=yes subdirs="$subdirs contrib/plugins" fi -- 2.39.5

1 0

Plans for 10.8.0 release (freeze on Wednesday 25 Sep)
by Jiri Denemark 18 Sep '24

18 Sep '24

We are getting close to 10.8.0 release of libvirt. To aim for the release on Tuesday 01 Oct I suggest entering the freeze on Wednesday 25 Sep and tagging RC2 on Friday 27 Sep. I hope this works for everyone. Jirka

1 0

[PATCH 0/2] qemu: Reject unsupported chardev '<protocol' settings
by Peter Krempa 18 Sep '24

18 Sep '24

See 2/2 Peter Krempa (2): conf: Convert 'protocol' field of TCP char device backend to proper type qemu: Reject unsupported chardev backend protocols src/conf/domain_conf.c | 11 +++------ src/conf/domain_conf.h | 2 +- src/qemu/qemu_validate.c | 19 +++++++++++++++ src/vmx/vmx.c | 7 +++--- ...rial-tcp-chardev-telnets.x86_64-latest.err | 1 + .../serial-tcp-chardev-telnets.xml | 23 +++++++++++++++++++ tests/qemuxmlconftest.c | 1 + 7 files changed, 51 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxmlconfdata/serial-tcp-chardev-telnets.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/serial-tcp-chardev-telnets.xml -- 2.46.0

2 3

[PATCH 0/8] qemu: Unify generators for commandline and monitor chardev backends
by Peter Krempa 18 Sep '24

18 Sep '24

Apart from having just one place to fix when changing chardev backends this also adds validation against the schema so we can spot deprecations early. Peter Krempa (8): qemu: capabilities: Explain that QEMU_CAPS_CHARDEV_JSON will be used in tests only qemuxmlconftest: Add 'chardev-backends' test case qemu: Introduce unified chardev backend config generator qemuxmlconftest: Add support for validating schema for 'chardev-add' qemuxmlconftest: Add test case for QMP schema validation of -chardev backends qemu: Move check for chardev backends which can't be hotplugged out of the monitor qemu: Use the new chardev backend JSON props generator also in the monitor qemu: monitor: Remove the old chardev backend generator src/qemu/meson.build | 1 + src/qemu/qemu_block.c | 9 +- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_chardev.c | 488 ++++++++++++++++++ src/qemu/qemu_chardev.h | 22 + src/qemu/qemu_command.c | 202 +------- src/qemu/qemu_hotplug.c | 51 +- src/qemu/qemu_monitor.c | 8 +- src/qemu/qemu_monitor.h | 4 +- src/qemu/qemu_monitor_json.c | 273 +--------- src/qemu/qemu_monitor_json.h | 4 +- tests/qemumonitorjsontest.c | 23 +- .../chardev-backends-json.x86_64-latest.args | 79 +++ .../chardev-backends-json.x86_64-latest.xml | 1 + .../qemuxmlconfdata/chardev-backends-json.xml | 1 + .../chardev-backends.x86_64-latest.args | 79 +++ .../chardev-backends.x86_64-latest.xml | 149 ++++++ tests/qemuxmlconfdata/chardev-backends.xml | 111 ++++ tests/qemuxmlconftest.c | 7 + 19 files changed, 1026 insertions(+), 488 deletions(-) create mode 100644 src/qemu/qemu_chardev.c create mode 100644 src/qemu/qemu_chardev.h create mode 100644 tests/qemuxmlconfdata/chardev-backends-json.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/chardev-backends-json.x86_64-latest.xml create mode 120000 tests/qemuxmlconfdata/chardev-backends-json.xml create mode 100644 tests/qemuxmlconfdata/chardev-backends.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/chardev-backends.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/chardev-backends.xml -- 2.46.0

2 16

[PATCH] rpm: Add riscv64 to arches_qemu_kvm
by Andrea Bolognani 18 Sep '24

18 Sep '24

The riscv64 architecture is not yet fully integrated into Fedora, but KVM support is already implemented across the stack and the Fedora package for QEMU is already set up to generate the qemu-kvm binary package when targeting it. Thanks: David Abdurachmanov <davidlt(a)rivosinc.com> Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 4dec7ace6f..c332fb4ff1 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -6,7 +6,7 @@ %define min_rhel 8 %define min_fedora 37 -%define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x +%define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x riscv64 %if 0%{?rhel} %if 0%{?rhel} > 8 %define arches_qemu_kvm x86_64 aarch64 s390x -- 2.46.0

2 1

[PATCH 0/5] network: a few fixes related to <forward mode='open'/>
by Laine Stump 17 Sep '24

17 Sep '24

While closing out the > 50 open tabs that had accumulated in one of my 3 browser windows, I came across a couple of upstream issues where I had posted a comment several months ago that I would fix some simple problem "tomorrow" (or maybe it was "next week"). Now that I've been reminded, I thought I should actually do that. Laine Stump (5): network: permit <forward mode='open'/> when a network has no IP address network: belatedly update an error message network: support setting firewalld zone for bridge device of open networks network: remove firewalld version check from networkSetBridgeZone() network: *un*set the firewalld zone while shutting down a network src/conf/network_conf.c | 5 +- src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 8 +++ src/network/bridge_driver_linux.c | 96 +++++++++++++++------------- src/network/bridge_driver_nop.c | 19 ++++++ src/network/bridge_driver_platform.h | 4 ++ src/util/virfirewalld.c | 23 +++++++ src/util/virfirewalld.h | 2 + 8 files changed, 112 insertions(+), 46 deletions(-) -- 2.46.0

2 15

[PATCH] network: Remove unused variable in networkDestroy
by Martin Kletzander 17 Sep '24

17 Sep '24

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed under the 'build-breaker' rule. Although I have no idea why only FreeBSD and macOS builds found that issue when both older and newer clang builds on Linux did not. src/network/bridge_driver.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 0ba62d986ff4..fe053f423ab5 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -3475,7 +3475,6 @@ static int networkDestroy(virNetworkPtr net) { virNetworkDriverState *driver = networkGetDriver(); - g_autoptr(virNetworkDriverConfig) cfg = virNetworkDriverGetConfig(driver); virNetworkObj *obj; virNetworkDef *def; int ret = -1; -- 2.46.0

1 0

[PATCH 0/8] Do more cleaning up after network objects upon start
by Martin Kletzander 17 Sep '24

17 Sep '24

This was initially inspired by https://issues.redhat.com/browse/RHEL-50968 which does things behind our back. However, I have found some other things when digging into the aforemention bug. I rebased, changed, rebased, refactored, and rebased again this branch so many times there might be a bunch of weird stuff I forgot to remove before posting. I hope I did not miss any, but one can never be sure ;) Martin Kletzander (8): network: Do not update network ports for inactive networks network: Do not call virNetworkObjUnsetDefTransient on start cleanup network: Move port deletion into the shutdown function network: Don't check if network is active in networkShutdownNetwork network: Clean up after inactive objects during start network: Try to read dnsmasq PIDs for inactive networks too network: Separate cleanup from networkRemoveInactive network: Clean up after disappeared transient inactive networks src/network/bridge_driver.c | 62 ++++++++++++++++++++++++++++++------- 1 file changed, 50 insertions(+), 12 deletions(-) -- 2.46.0

3 19