1. Patchew
  2. QEMU
  3. View series

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

Leesoo Ahn posted 1 patch 1 month ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260623-guest-panic-unhandle-v1-1-6adfb6d4221e@ooseel.net
Maintainers: Alexander Graf <agraf@csgraf.de>, Peter Maydell <peter.maydell@linaro.org>
target/arm/hvf/hvf.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Leesoo Ahn 1 month ago 
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 <lsahn@ooseel.net>
---
 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));
     }
 
     /* flush any changed cpu state back to HVF */

---
base-commit: b83371668192a705b878e909c5ae9c1233cbd5fb
change-id: 20260623-guest-panic-unhandle-4921d2aa69fb

Best regards,
--  
Leesoo Ahn <lsahn@ooseel.net>
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Peter Maydell 2 weeks, 1 day ago 
On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <lsahn@ooseel.net> 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 <lsahn@ooseel.net>
> ---
>  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
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Philippe Mathieu-Daudé 2 weeks, 1 day ago 
On 10/7/26 17:37, Peter Maydell wrote:
> On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <lsahn@ooseel.net> 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 <lsahn@ooseel.net>
>> ---
>>   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?
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Peter Maydell 1 week, 6 days ago 
On Fri, 10 Jul 2026 at 23:56, Philippe Mathieu-Daudé
<philmd@oss.qualcomm.com> wrote:
>
> On 10/7/26 17:37, Peter Maydell wrote:
> > On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <lsahn@ooseel.net> 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 <lsahn@ooseel.net>
> >> ---
> >>   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/alSqlDRT9L8OqAso@redhat.com/T/#m9ab2f4a819e33cd5ac0f6d22ab30f98a0d599866

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/8D0BCB24-BB1B-40EF-A361-0F79D65600AE@unpredictable.fr/

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.

-- PMM
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Leesoo Ahn 1 week, 2 days ago 
2026년 7월 13일 (월) 오후 6:34, Peter Maydell <peter.maydell@linaro.org>님이 작성:
>
> On Fri, 10 Jul 2026 at 23:56, Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
> >
> > On 10/7/26 17:37, Peter Maydell wrote:
> > > On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <lsahn@ooseel.net> 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 <lsahn@ooseel.net>
> > >> ---
> > >>   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/alSqlDRT9L8OqAso@redhat.com/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/8D0BCB24-BB1B-40EF-A361-0F79D65600AE@unpredictable.fr/
>
> 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
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Peter Maydell 1 week, 2 days ago 
On Thu, 16 Jul 2026 at 18:27, Leesoo Ahn <lsahn@ooseel.net> wrote:
>
> 2026년 7월 13일 (월) 오후 6:34, Peter Maydell <peter.maydell@linaro.org>님이 작성:
> >
> > On Fri, 10 Jul 2026 at 23:56, Philippe Mathieu-Daudé
> > <philmd@oss.qualcomm.com> wrote:
> > >
> > > On 10/7/26 17:37, Peter Maydell wrote:
> > > > On Tue, 23 Jun 2026 at 13:56, Leesoo Ahn <lsahn@ooseel.net> 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 <lsahn@ooseel.net>
> > > >> ---
> > > >>   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/8D0BCB24-BB1B-40EF-A361-0F79D65600AE@unpredictable.fr/
> >
> > 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
Re: [PATCH] target/arm/hvf: panic the guest if an unhandled exception occurs
Posted by Leesoo Ahn 2 weeks, 1 day ago 
ping

2026년 6월 23일 (화) 오후 9:56, Leesoo Ahn <lsahn@ooseel.net>님이 작성:
>
> 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 <lsahn@ooseel.net>
> ---
>  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));
>      }
>
>      /* flush any changed cpu state back to HVF */
>
> ---
> base-commit: b83371668192a705b878e909c5ae9c1233cbd5fb
> change-id: 20260623-guest-panic-unhandle-4921d2aa69fb
>
> Best regards,
> --
> Leesoo Ahn <lsahn@ooseel.net>
>

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.