From: Paolo Bonzini <pbonzini@redhat.com>
To: "Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Max Reitz <mreitz@redhat.com>
Subject: Re: Thread safety of coroutine-sigaltstack
Date: Thu, 21 Jan 2021 18:24:07 +0100 [thread overview]
Message-ID: <a944d86c-2871-3301-6f42-f5368a122593@redhat.com> (raw)
In-Reply-To: <CAFEAcA-zVvu+16xxjCvXqeZxZMqppUUb7aQkL-5nBTNY+JeyGg@mail.gmail.com>
On 21/01/21 17:44, Peter Maydell wrote:
> On Thu, 21 Jan 2021 at 16:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> FWIW The libucontext impl is all ASM based and has coverage for all the
>> arches we care about:
>>
>> https://github.com/kaniini/libucontext
>>
>> so doesn't seem like there's a need for coroutine-asm if we can rely
>> on libucontext for portability where neede.
>
> The README for that notes a couple of pretty major omissions:
> * it doesn't handle floating point registers
> * it doesn't do anything about the signal mask
> I'm pretty sure that not handling the fp regs could cause breakage
> for Arm at least (depending on what the compiler chooses to do
> in the functions that work with the ucontext functions). The
> signal mask stuff might be OK for us because of the carefully
> limited use we make of the ucontext functions, but it would be
> a bit of a pain to have to analyse that code for both sets of semantics.
The lack of signal mask handling is an improvement for us. :) We want
the signal mask to be per thread, not per coroutine.
Floating point however is an issue if they don't save-restore v8-v15
(for aarch64, I don't remember what the AAPCS32 says).
Paolo
next prev parent reply other threads:[~2021-01-21 17:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 16:26 Thread safety of coroutine-sigaltstack Max Reitz
2021-01-20 16:50 ` Paolo Bonzini
2021-01-20 16:58 ` Eric Blake
2021-01-20 17:25 ` Laszlo Ersek
2021-01-21 9:27 ` Max Reitz
2021-01-21 13:34 ` Laszlo Ersek
2021-01-21 15:42 ` Max Reitz
2021-01-21 16:04 ` Daniel P. Berrangé
2021-01-21 16:05 ` Laszlo Ersek
2021-01-21 15:14 ` Paolo Bonzini
2021-01-21 16:07 ` Daniel P. Berrangé
2021-01-21 16:44 ` Peter Maydell
2021-01-21 17:24 ` Paolo Bonzini [this message]
2021-01-22 20:38 ` Laszlo Ersek
2021-01-22 21:34 ` Laszlo Ersek
2021-01-22 21:41 ` Laszlo Ersek
2021-01-22 7:55 ` Markus Armbruster
2021-01-22 8:48 ` Max Reitz
2021-01-22 10:14 ` Peter Maydell
2021-01-22 10:16 ` Max Reitz
2021-01-22 12:24 ` Laszlo Ersek
2021-01-23 0:06 ` Laszlo Ersek
2021-01-23 13:35 ` Peter Maydell
2021-01-25 22:15 ` Laszlo Ersek
2021-01-25 22:45 ` Paolo Bonzini
2021-01-26 8:57 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a944d86c-2871-3301-6f42-f5368a122593@redhat.com \
--to=pbonzini@redhat.com \
--cc=berrange@redhat.com \
--cc=kwolf@redhat.com \
--cc=lersek@redhat.com \
--cc=mreitz@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.