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. -- PMM
