On Mon, 9 Mar 2026, Ani Sinha wrote:
> > > > On 9 Mar 2026, at 4:34 PM, Harsh Prateek Bora <[email protected]> wrote: > > > > Hi Ani, Paolo, > > > > I think the problem lies here: > > > > For archs which doesnt support vm fd change, we are baling out as below in > > kvm_reset_vmfd. > > > > > > /* > > * bail if the current architecture does not support VM file > > * descriptor change. > > */ > > if (!kvm_arch_supports_vmfd_change()) { > > error_report("This target architecture does not support KVM VM " > > "file descriptor change."); > > return -EOPNOTSUPP; > > } > > > > However, when rebuild_guest (kvm_reset_vmfd) is called in > > qemu_system_reset here: > > > > if ((reason == SHUTDOWN_CAUSE_GUEST_RESET || > > reason == SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET) && > > (current_machine->new_accel_vmfd_on_reset || > > !cpus_are_resettable())) { > > if (ac->rebuild_guest) { > > ret = ac->rebuild_guest(current_machine); > > if (ret < 0) { > > error_report("unable to rebuild guest: %s(%d)", > > strerror(-ret), ret); > > vm_stop(RUN_STATE_INTERNAL_ERROR); > > } else { > > info_report("virtual machine state has been rebuilt with new > > " > > "guest file handle."); > > guest_state_rebuilt = true; > > } > > } else if (!cpus_are_resettable()) { > > error_report("accelerator does not support reset!"); > > } else { > > error_report("accelerator does not support rebuilding guest > > state," > > " proceeding with normal reset!"); > > } > > } > > > > > > it just does a vm_stop if rebuild_guest returns < 0. > > > > IMHO, This should handle -EOPNOTSUPP gracefully. > > Please advise if this needs to be taken care differently? 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? > > >> #2 0x00007ffff58aa220 in __futex_abstimed_wait_common64 > >> (futex_word=0x10131ba10, expected=0, op=393, abstime=0x0, cancel=true) at > >> futex-internal.c:57 > >> #3 __futex_abstimed_wait_common (futex_word=0x10131ba10, expected=0, > >> clockid=0, abstime=<optimized out>, private=0, cancel=true) at futex- > >> internal.c:87 > >> #4 __GI___futex_abstimed_wait_cancelable64 (futex_word=0x10131ba10, > >> expected=0, clockid=0, abstime=0x0, private=0) at futex-internal.c:139 > >> #5 0x00007ffff58ae0bc in __pthread_cond_wait_common (cond=0x10131b9f0, > >> mutex=0x101222ce0 <bql>, clockid=0, abstime=0x0) at pthread_cond_wait.c:426 > >> #6 ___pthread_cond_wait (cond=0x10131b9f0, mutex=0x101222ce0 <bql>) at > >> pthread_cond_wait.c:458 > >> #7 0x0000000100b9bea8 in qemu_cond_wait_impl (cond=0x10131b9f0, > >> mutex=0x101222ce0 <bql>, file=0x100c59900 "../system/cpus.c", line=472) at > >> ../util/qemu-thread-posix.c:240 > >> #8 0x00000001006a0408 in qemu_process_cpu_events (cpu=0x1019dd260) at > >> ../system/cpus.c:472 > >> #9 0x0000000100913354 in kvm_vcpu_thread_fn (arg=0x1019dd260) at ../ > >> accel/kvm/kvm-accel-ops.c:50 > >> #10 0x0000000100b9b30c in qemu_thread_start (args=0x1019f1fe0) at ../ > >> util/qemu-thread-posix.c:414 > >> #11 0x00007ffff58aed94 in start_thread (arg=0x7ffff0bce320) at > >> pthread_create.c:448 > >> #12 0x00007ffff59555f8 in __GI___clone3 () at ../sysdeps/unix/sysv/ > >> linux/powerpc/powerpc64/clone3.S:114 > >> Thanks, > >> Misbah Anjum N <[email protected]> > >> On 2026-03-06 16:22, Misbah Anjum N wrote: > >>> Hi, > >>> I'm reporting a critical regression on ppc64le that causes all KVM > >>> guests to hang immediately during startup. Git bisect identified > >>> commit 98884e0cc10997a17ce9abfd6ff10be19224ca6a as the first bad > >>> commit. The commit completely breaks KVM functionality on ppc64le. > >>> > >>> Regression Details: > >>> Working Version: QEMU 10.2.50 (v10.2.0-1669-gffcf1a7981) > >>> Broken Version: QEMU 10.2.50 (v10.2.0-1816-g3fb456e9a0) > >>> Bad Commit: 98884e0cc10997a17ce9abfd6ff10be19224ca6a "accel/kvm: add > >>> changes required to support KVM VM file descriptor change" > >>> Commit Link: > >>> https://gitlab.com/qemu-project/qemu/-/ > >>> commit/98884e0cc10997a17ce9abfd6ff10be19224ca6a > >>> > >>> Environment: > >>> Host: Fedora 42, Kernel 7.0.0-rc2, Power11 (ppc64le) > >>> Libvirt: 12.1.0 > >>> Guest: Fedora 42, Kernel 7.0.0-rc2 > >>> Machine Type: pseries with KVM acceleration > >>> > >>> Build Configuration: > >>> git clone https://gitlab.com/qemu-project/qemu.git > >>> cd qemu > >>> git submodule init > >>> git submodule update --recursive > >>> ./configure --target-list=ppc64-softmmu --disable-tcg --prefix=/usr > >>> make && make install > >>> > >>> Reproduction: > >>> Using virt-install: > >>> /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate > >>> --name 'avocado-vt-vm1' --machine pseries --memory=32768 > >>> --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics > >>> --os-variant rhel8.0 --serial pty --memballoon model=virtio > >>> --controller type=scsi,model=virtio-scsi --disk > >>> path=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel- > >>> ppc64le.qcow2,bus=scsi,size=10,format=qcow2 > >>> --network=bridge=virbr0,model=virtio --boot > >>> emulator=/usr/bin/qemu-system-ppc64 > >>> Result: Starting install... > >>> <hangs indefinitely with no output> > >>> > >>> Using direct QEMU command: > >>> /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 > >>> Result: <hangs indefinitely with no output> > >>> > >>> Analysis: > >>> The commit introduces VM file descriptor change support with > >>> architecture-specific hooks. > >>> I attempted the following fixes without success: > >>> 1. Changed abort() to return 0; in stubs/kvm.c > >>> 2. Added early return in kvm_reset_vmfd() when > >>> kvm_arch_supports_vmfd_change() returns false > >>> > >>> Git Bisect Log: > >>> # git bisect bad > >>> 98884e0cc10997a17ce9abfd6ff10be19224ca6a is the first bad commit > >>> commit 98884e0cc10997a17ce9abfd6ff10be19224ca6a (HEAD) > >>> Author: Ani Sinha <[email protected]> > >>> Date: Wed Feb 25 09:19:10 2026 +0530 > >>> > >>> accel/kvm: add changes required to support KVM VM file descriptor > >>> change > >>> > >>> This change adds common kvm specific support to handle KVM VM file > >>> descriptor > >>> change. KVM VM file descriptor can change as a part of > >>> confidential guest reset > >>> mechanism. A new function api kvm_arch_on_vmfd_change() per > >>> architecture platform is added in order to implement architecture > >>> specific > >>> changes required to support it. A subsequent patch will add x86 > >>> specific > >>> implementation for kvm_arch_on_vmfd_change() as currently only x86 > >>> supports > >>> confidential guest reset. > >>> > >>> Signed-off-by: Ani Sinha <[email protected]> > >>> Link: https://lore.kernel.org/r/20260225035000.385950-6- > >>> [email protected] > >>> Signed-off-by: Paolo Bonzini <[email protected]> > >>> > >>> MAINTAINERS | 6 ++++++ > >>> accel/kvm/kvm-all.c | 88 > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> +++++++++++++++--- > >>> accel/kvm/trace-events | 1 + > >>> include/system/kvm.h | 3 +++ > >>> stubs/kvm.c | 22 ++++++++++++++++++++++ > >>> stubs/meson.build | 1 + > >>> target/i386/kvm/kvm.c | 10 ++++++++++ > >>> 7 files changed, 128 insertions(+), 3 deletions(-) > >>> create mode 100644 stubs/kvm.c > >>> > >>> # git bisect log > >>> git bisect start > >>> git bisect good ffcf1a7981793973ffbd8100a7c3c6042d02ae23 > >>> git bisect bad 3fb456e9a0e9eef6a71d9b49bfff596a0f0046e9 > >>> git bisect bad e76c30bb13ecb9dc716fa629954bfb6253056ce2 > >>> git bisect good 9bdc612a18588975f5776ee4e562df607fea1b2c > >>> git bisect bad 40c015e96942fd2a3e4d5ace6063b3333a3dd372 > >>> git bisect good df8df3cb6b743372ebb335bd8404bc3d748da350 > >>> git bisect bad 0f53f021ad1ede28dc8944686544e496cab02e5e > >>> git bisect bad 9f0c2b3032639315faf141010a2603b0dbf56230 > >>> git bisect bad 98884e0cc10997a17ce9abfd6ff10be19224ca6a > >>> first bad commit: [98884e0cc10997a17ce9abfd6ff10be19224ca6a] > >>> > >>> Thanks, > >>> Misbah Anjum N <[email protected]> > > > >
