On 01/22/21 11:14, Peter Maydell wrote: > On Fri, 22 Jan 2021 at 08:50, Max Reitz <mre...@redhat.com> wrote: >> >> On 20.01.21 18:25, Laszlo Ersek wrote: >> >> [...] >> >>> A simple grep for SIGUSR2 seems to indicate that SIGUSR2 is not used >>> by system emulation for anything else, in practice. Is it possible >>> to dedicate SIGUSR2 explicitly to coroutine-sigaltstack, and set up >>> the action beforehand, from some init function that executes on a >>> "central" thread, before qemu_coroutine_new() is ever called? >> >> I wrote a patch to that effect, but just before sending I wondered >> whether SIGUSR2 cannot be registered by the "guest" in user-mode >> emulation, and whether that would then break coroutines from there >> on. >> >> (I have no experience dealing with user-mode emulation, but it does >> look like the guest can just register handlers for any signal but >> SIGSEGV and SIGBUS.) > > Yes, SIGUSR2 is for the guest in user-emulation mode.
Yes, my grep found those occurrences of SIGUSR2 of course. > OTOH do we even use the coroutine code in user-emulation mode? I assumed not. I assumed coroutines were only used by the block system, and user mode emulation is about running userspace Linux programs -- virtual disks are not emulated for those. > Looking at the meson.build files, we only add the coroutine_*.c to > util_ss if 'have_block', and we set have_block = have_system or > have_tools. I think (but have not checked) that that means we will > build and link the object file into the user-mode binaries if you > happen to build them in the same run as system-mode binaries, but > won't build them in if you built the user-mode binaries as a separate > build. Huh. > Which is odd and probably worth fixing, but does mean we > know that we aren't actually using coroutines in user-mode. Thanks for checking! Laszlo > (Also user-mode really means Linux or BSD and I think both of > those have working ucontext.) > > thanks > -- PMM >
