[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/7] semihosting: proper QEMU exit on semihosted exit syscall
From: |
Luc Michel |
Subject: |
Re: [PATCH 0/7] semihosting: proper QEMU exit on semihosted exit syscall |
Date: |
Mon, 20 Jun 2022 17:10:37 +0200 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
On 15:35 Mon 20 Jun , Peter Maydell wrote:
> On Mon, 20 Jun 2022 at 15:25, Luc Michel <lmichel@kalray.eu> wrote:
> > This series implements a clean way for semihosted exit syscalls to
> > terminate QEMU with a given return code.
> >
> > Until now, exit syscalls implementations consisted in calling exit()
> > with the wanted return code. The problem with this approach is that
> > other CPUs are not properly stopped, leading to possible crashes in
> > MTTCG mode, especially when at_exit callbacks have been registered. This
> > can be the case e.g., when plugins are in use. Plugins can register
> > at_exit callbacks. Those will be called on the CPU thread the exit
> > syscall is comming from, while other CPUs can continue to run and thus
> > call other plugin callbacks.
>
> The other option would be to say "if you register an atexit
> callback in your plugin that's your problem to sort out" :-)
> There's lots of situations where code inside QEMU might just
> call exit(), not just this one. (Mostly these are "we detected
> an error and decided to just bail out" codepaths.)
Sorry I was a bit unclear. I meant plugins using the
qemu_plugin_register_atexit_cb() register function, not directly calling
atexit(). This function documentation stats:
"Plugins should be able to free all their resources at this point much like
after a reset/uninstall callback is called."
If other CPUs are still running, this is not possible. I guess it's
reasonable to assume CPUs have reached a quiescent state when those
callbacks are called.
>
> Is there a situation where we get a crash that doesn't involve
> code in a plugin doing something odd?
I'm not sure... I always feel a bit uncomfortable calling exit() from
a CPU thread in the middle of a translation block :)
I guess if you're monitoring QEMU through a QMP connection, it's better
to have a proper exit reason than having the connection suddenly
dropped. I guess the semihosting mode is not that popular among QEMU
users so there are probably other corner cases I'm not aware about.
Thanks,
Luc
- [PATCH] accel/tcg/cpu-exec: fix precise single-stepping after interrupt, (continued)
- [PATCH] accel/tcg/cpu-exec: fix precise single-stepping after interrupt, Luc Michel, 2022/06/20
- [PATCH 2/7] semihosting: add the semihosting_exit_request function, Luc Michel, 2022/06/20
- [PATCH 7/7] target/xtensa: use semihosting_exit_request on semihosted exit syscall, Luc Michel, 2022/06/20
- [PATCH 1/7] softmmu: add qemu_[set|get]_exit_status functions, Luc Michel, 2022/06/20
- [PATCH 4/7] target/m68k: use semihosting_exit_request on semihosted exit syscall, Luc Michel, 2022/06/20
- [PATCH 3/7] semihosting/arm-compat-semi: use semihosting_exit_request, Luc Michel, 2022/06/20
- [PATCH 6/7] target/nios2: use semihosting_exit_request on semihosted exit syscall, Luc Michel, 2022/06/20
- [PATCH 5/7] target/mips: use semihosting_exit_request on semihosted exit syscall, Luc Michel, 2022/06/20
- Re: [PATCH 0/7] semihosting: proper QEMU exit on semihosted exit syscall, Peter Maydell, 2022/06/20
- Re: [PATCH 0/7] semihosting: proper QEMU exit on semihosted exit syscall,
Luc Michel <=
- Re: [PATCH 0/7] semihosting: proper QEMU exit on semihosted exit syscall, Richard Henderson, 2022/06/20