On 15:35 Mon 20 Jun , Peter Maydell wrote: > On Mon, 20 Jun 2022 at 15:25, Luc Michel <[email protected]> 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
