On Fri, 10 Jul 2026 at 23:56, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 10/7/26 17:37, Peter Maydell wrote: > > On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <[email protected]> wrote: > >> > >> It's worth cleaning up all resources that the guest taking and to quit > >> if an exception in el1 could not be resolved. > >> > >> Otherwise, the guest will get in the infinite black-hole by > >> unmodified pc. > >> > >> Signed-off-by: Leesoo Ahn <[email protected]> > >> --- > >> target/arm/hvf/hvf.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c > >> index 8b902c6882..4358cf90e8 100644 > >> --- a/target/arm/hvf/hvf.c > >> +++ b/target/arm/hvf/hvf.c > >> @@ -2533,6 +2533,7 @@ static int hvf_handle_exception(CPUState *cpu, > >> hv_vcpu_exit_exception_t *excp) > >> cpu_synchronize_state(cpu); > >> trace_hvf_exit(syndrome, ec, env->pc); > >> error_report("0x%llx: unhandled exception ec=0x%x", env->pc, ec); > >> + qemu_system_guest_panicked(cpu_get_crash_info(cpu)); > >> } > > > > We should do something here, but my question is whether > > qemu_system_guest_panicked() is the right thing. We mostly > > use that for "the guest OS wants to tell QEMU that it has > > panicked, so QEMU can reflect that to the user and perhaps > > reboot or exit", though we do in a few places use it for > > things that are more like "we don't handle this case". I'm > > not sure exactly what the right thing to do here is, though. > > We usually abort() for programming errors (here unimplemented > case) and don't let the guest mis-behave.
We've definitely used that strategy in the past (either directly, or indirectly via hw_abort() or cpu_abort()), but I think these days we'd prefer not to let the guest trigger QEMU to abort(). Some of those cases we've been able to convert to LOG_GUEST_ERROR and continue in some manner, but some cases are just not continuable from. I think we could probably use a better mechanism for "something went badly wrong and we can't continue executing the guest", where e.g. we can suspend the VM and let the operator look at its state: https://lore.kernel.org/qemu-devel/[email protected]/T/#m9ab2f4a819e33cd5ac0f6d22ab30f98a0d599866 For this specific patch: what is the case where we get into this codepath (and in particular what is the EC_FOO exception subtype)? Maybe the fix is to handle that case. Compare an earlier thread: https://lore.kernel.org/qemu-devel/[email protected]/ If we're getting here by falling through from EC_INSNABORT, I think that can happen if the guest tries to execute from an MMIO region. -- PMM
