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.
Maybe call the mis-named hw_error() method to dump something
before dying?
