Hi Ani and Paolo,
We have tested the code by applying both the original commit
(98884e0cc10997a17ce9abfd6ff10be19224ca6a) and your fix patch (commit
9e5a6945181d4c1fce7f8438e1b6213f1eb79c14) on ppc64le.
However, the issue persists. We've conducted GDB debugging that shows
the hang is occurring in a different location than what the fix
addresses.
Since the original patch is breaking KVM guest bringup completely on
ppc64le, and the fix patch does not resolve the issue, given the
severity of this regression (complete KVM breakage on ppc64le), we
should either find a quick fix or consider reverting the patch until a
proper solution can be identified.
Analysis:
1. This is not a confidential guest. This is a regular KVM guest running
on ppc64le.
2. The execution flow shows that qemu_system_reset() completes
successfully and never enters the code path at line 529-543
3. The hang occurs later in qemu_default_main() at system/main.c:49,
after calling bql_lock()
4. The ppc KVM guest boots fine with the previous commit -
df8df3cb6b743372ebb335bd8404bc3d748da350
5. This suggests the issue is not with error handling of -EOPNOTSUPP
during reset, but bql_lock() getting stuck in qemu_default_main()
GDB Trace Analysis:
We set breakpoints at qemu_system_reset() and qemu_default_main() to
trace the execution flow. The system successfully completes
qemu_system_reset() without entering the problematic code path where the
fix provided by you applies (system/runstate.c:529-543).
# gdb --args /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine
pseries,accel=kvm -enable-kvm -m 32768 -smp
32,sockets=1,cores=32,threads=1 -nographic -serial pty -device
virtio-balloon -device virtio-scsi-pci,id=scsi0 -drive
file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive-scsi0-0-0,format=qcow2
-device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0 -netdev
bridge,id=net0,br=virbr0 -device virtio-net-pci,netdev=net0
(gdb) handle SIGUSR1 pass nostop noprint
Signal Stop Print Pass to program Description
SIGUSR1 No No Yes User defined signal 1
(gdb) b qemu_system_reset
Breakpoint 1 at 0x69a688: file ../system/runstate.c, line 510.
(gdb) b qemu_default_main
Breakpoint 2 at 0xa9aeb8: file ../system/main.c, line 45.
(gdb) r
Starting program: /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1
-machine pseries,accel=kvm -enable-kvm -m 32768 -smp
32,sockets=1,cores=32,threads=1 -nographic -serial pty -device
virtio-balloon -device virtio-scsi-pci,id=scsi0 -drive
file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive-scsi0-0-0,format=qcow2
-device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0 -netdev
bridge,id=net0,br=virbr0 -device virtio-net-pci,netdev=net0
Thread 1 "qemu-system-ppc" hit Breakpoint 1, qemu_system_reset
(reason=reason@entry=SHUTDOWN_CAUSE_NONE) at ../system/runstate.c:513
513 AccelClass *ac = ACCEL_GET_CLASS(current_accel());
(gdb) n
517 mc = current_machine ? MACHINE_GET_CLASS(current_machine) :
NULL;
(gdb) n
519 cpu_synchronize_all_states();
(gdb) n
521 switch (reason) {
(gdb) n
529 if (!cpus_are_resettable() &&
(gdb) n
553 if (mc && mc->reset) {
(gdb) n
554 mc->reset(current_machine, type);
(gdb) n
558 switch (reason) {
(gdb) n
574 if (cpus_are_resettable()) {
(gdb) n
583 cpu_synchronize_all_post_reset();
(gdb) n
587 vm_set_suspended(false);
(gdb) n
qdev_machine_creation_done () at ../hw/core/machine.c:1814
1814 register_global_state();
(gdb) n
qemu_machine_creation_done (errp=0x10123e028 <error_fatal>) at
../system/vl.c:2785
2785 if (machine->cgs && !machine->cgs->ready) {
(gdb) n
2791 foreach_device_config_or_exit(DEV_GDB, gdbserver_start);
(gdb) n
2793 if (!vga_interface_created && !default_vga &&
(gdb) n
qmp_x_exit_preconfig (errp=errp@entry=0x10123e028 <error_fatal>) at
../system/vl.c:2815
2815 if (loadvm) {
(gdb) n
2820 if (replay_mode != REPLAY_MODE_NONE) {
(gdb) n
2824 if (incoming) {
(gdb) n
2837 } else if (autostart) {
(gdb) n
2838 qmp_cont(NULL);
(gdb) n
qemu_init (argc=<optimized out>, argv=<optimized out>) at
../system/vl.c:3849
3849 qemu_init_displays();
(gdb) n
3850 accel_setup_post(current_machine);
(gdb) n
3851 if (migrate_mode() != MIG_MODE_CPR_EXEC) {
(gdb) n
3852 os_setup_post();
(gdb) n
3854 resume_mux_open();
(gdb) n
main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:84
84 bql_unlock();
(gdb) n
85 replay_mutex_unlock();
(gdb) n
87 if (qemu_main) {
(gdb) n
93 qemu_default_main(NULL);
(gdb) n
Thread 1 "qemu-system-ppc" hit Breakpoint 2, qemu_default_main
(opaque=opaque@entry=0x0) at ../system/main.c:48
48 replay_mutex_lock();
(gdb) n
49 bql_lock();
(gdb) n
<hangs>
<system becomes unresponsive at this point>
Thanks,
Misbah Anjum N <[email protected]>
On 2026-03-09 18:53, Ani Sinha wrote:
Yes seems this is an issue and I will fix it. Not sure if the fix will
address your issue though ...
Can you try the following patch?
From 9e5a6945181d4c1fce7f8438e1b6213f1eb79c14 Mon Sep 17 00:00:00 2001
From: Ani Sinha <[email protected]>
Date: Mon, 9 Mar 2026 18:44:40 +0530
Subject: [PATCH] Fix reset for non-x86 archs that do not support reset
yet
Signed-off-by: Ani Sinha <[email protected]>
---
system/runstate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/system/runstate.c b/system/runstate.c
index eca722b43c..c1f41284c9 100644
--- a/system/runstate.c
+++ b/system/runstate.c
@@ -531,10 +531,12 @@ void qemu_system_reset(ShutdownCause reason)
(current_machine->new_accel_vmfd_on_reset ||
!cpus_are_resettable())) {
if (ac->rebuild_guest) {
ret = ac->rebuild_guest(current_machine);
- if (ret < 0) {
+ if (ret < 0 && ret != -EOPNOTSUPP) {
error_report("unable to rebuild guest: %s(%d)",
strerror(-ret), ret);
vm_stop(RUN_STATE_INTERNAL_ERROR);
+ } else if (ret == -EOPNOTSUPP) {
+ error_report("accelerator does not support reset!");
} else {
info_report("virtual machine state has been rebuilt
with new "
"guest file handle.");
--
2.42.0
Is this a confidential guest that cannot be normally reset?
