2026년 7월 13일 (월) 오후 6:34, Peter Maydell <[email protected]>님이 작성: > > 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
I keep my eyes on the thread and agree with your idea. > > 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. EC_DATABORT already deals with traps by accessing MMIO regions. Yet I have no idea what kind of instruction abort could be raised in MMIO. BR, Leesoo
