On Thu, 16 Jul 2026 at 18:27, Leesoo Ahn <[email protected]> wrote: > > 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)); > > > >> }
> > 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. Yeah, we can't support emulating of execution from an MMIO region with hvf. I think it will only really happen if the guest has a bug and jumps to a bad address that happens to have a device. Did you submit this patch because you saw a VM get into this state? What did the guest do to cause it? thanks -- PMM
