Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs

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