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. OTOH do we > even use the coroutine code in user-emulation mode? 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,
I did that, first running ./configure \ --enable-debug \ --target-list==x86_64-softmmu,x86_64-linux-user \ --with-coroutine=sigaltstack Then I checked the "qemu-system-x86_64" and "qemu-x86_64" binaries with "nm". Only the former contains "coroutine_init": 00000000009725e4 t coroutine_init So I believe the coroutine object file(s) are not even linked into the user-mode emulators. (coroutine_init() is a constructor function, so I think it would be preserved otherwise, even if it had no explicit caller.) I tried a different approach too: an #error in "coroutine-sigaltstack.c", if CONFIG_LINUX_USER were #defined. But that aborted the build, due to CONFIG_LINUX_USER being poisoned in the first place. Maybe that result was already enough to answer the question, but I wasn't sure, hence the check with "nm". Thanks, Laszlo > but won't > build them in if you built the user-mode binaries as a separate > build. Which is odd and probably worth fixing, but does mean we > know that we aren't actually using coroutines in user-mode. > (Also user-mode really means Linux or BSD and I think both of > those have working ucontext.) > > thanks > -- PMM >