On 01/25/21 23:45, Paolo Bonzini wrote:
> On 25/01/21 23:15, Laszlo Ersek wrote:
>>
>> - How does this case differ from the registration of types? type_init()
>> is a constructor function, and it generally ends up adding some
>> structures with function pointers (I reckon) via type_table_add(). The
On 25/01/21 23:15, Laszlo Ersek wrote:
- How does this case differ from the registration of types? type_init()
is a constructor function, and it generally ends up adding some
structures with function pointers (I reckon) via type_table_add(). The
main executable doesn't call into the device code
On 01/23/21 14:35, Peter Maydell wrote:
> On Sat, 23 Jan 2021 at 00:06, Laszlo Ersek wrote:
>> On 01/22/21 11:14, Peter Maydell wrote:
>>> 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 sa
On Sat, 23 Jan 2021 at 00:06, Laszlo Ersek wrote:
> On 01/22/21 11:14, Peter Maydell wrote:
> > 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 t
On 01/22/21 11:14, Peter Maydell wrote:
> On Fri, 22 Jan 2021 at 08:50, Max Reitz 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
>>
On 01/22/21 22:34, Laszlo Ersek wrote:
> On 01/22/21 21:38, Laszlo Ersek wrote:
>> The behavior of "savemask=0" is a platform trait that platforms are not
>> required to document (the behavior is unspecified, not
>> implementation-defined), so it really boils down to where this code
>> actually ru
On 01/22/21 21:38, Laszlo Ersek wrote:
> On 01/21/21 18:24, Paolo Bonzini wrote:
>> On 21/01/21 17:44, Peter Maydell wrote:
>>> On Thu, 21 Jan 2021 at 16:10, Daniel P. Berrangé
>>> wrote:
FWIW The libucontext impl is all ASM based and has coverage for all the
arches we care about:
>
On 01/21/21 18:24, Paolo Bonzini wrote:
> On 21/01/21 17:44, Peter Maydell wrote:
>> On Thu, 21 Jan 2021 at 16:10, Daniel P. Berrangé
>> wrote:
>>> FWIW The libucontext impl is all ASM based and has coverage for all the
>>> arches we care about:
>>>
>>> https://github.com/kaniini/libucontext
>
On 01/22/21 11:14, Peter Maydell wrote:
> On Fri, 22 Jan 2021 at 08:50, Max Reitz 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
>>> t
On 22.01.21 11:14, Peter Maydell wrote:
On Fri, 22 Jan 2021 at 08:50, Max Reitz 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 exp
On Fri, 22 Jan 2021 at 08:50, Max Reitz 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-siga
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
Paolo Bonzini writes:
> On 21/01/21 10:27, Max Reitz wrote:
>> Sure, I can do that.
>> I agree that there probably are better solutions than to wrap
>> everything in a lock. OTOH, it looks to me like this lock is the
>> most simple solution. If Daniel is right[1] and we should drop
>> coroutin
On 21/01/21 17:44, Peter Maydell wrote:
On Thu, 21 Jan 2021 at 16:10, Daniel P. Berrangé 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
On Thu, 21 Jan 2021 at 16:10, Daniel P. Berrangé 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 por
On Thu, Jan 21, 2021 at 04:14:21PM +0100, Paolo Bonzini wrote:
> On 21/01/21 10:27, Max Reitz wrote:
> >
> > Sure, I can do that.
> >
> > I agree that there probably are better solutions than to wrap everything
> > in a lock. OTOH, it looks to me like this lock is the most simple
> > solution.
On 01/21/21 16:42, Max Reitz wrote:
> Perhaps we have the policy of “If another process can send signals, then
> we consider it to have full control over qemu, like a debugger.”
That's what I had more or less in mind, yes; see e.g.
https://man7.org/linux/man-pages/man2/ptrace.2.html
EPER
On Thu, Jan 21, 2021 at 04:42:09PM +0100, Max Reitz wrote:
> On 21.01.21 14:34, Laszlo Ersek wrote:
> > On 01/21/21 10:27, Max Reitz wrote:
> > SUSv3 marked ucontext functions obsolescent:
> >
> > https://pubs.opengroup.org/onlinepubs/95399/functions/makecontext.html#tag_03_356_08
> >
> > and
On 21.01.21 14:34, Laszlo Ersek wrote:
On 01/21/21 10:27, Max Reitz wrote:
On 20.01.21 18:25, Laszlo Ersek wrote:
On 01/20/21 17:26, Max Reitz wrote:
Hi,
I’ve run into trouble with Vladimir’s async backup series on MacOS,
namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
T
On 21/01/21 10:27, Max Reitz wrote:
Sure, I can do that.
I agree that there probably are better solutions than to wrap everything
in a lock. OTOH, it looks to me like this lock is the most simple
solution. If Daniel is right[1] and we should drop
coroutine-sigaltstack altogether (at some p
On 01/21/21 10:27, Max Reitz wrote:
> On 20.01.21 18:25, Laszlo Ersek wrote:
>> On 01/20/21 17:26, Max Reitz wrote:
>>> Hi,
>>>
>>> I’ve run into trouble with Vladimir’s async backup series on MacOS,
>>> namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
>>>
>>> Turns out this is
On 20.01.21 18:25, Laszlo Ersek wrote:
On 01/20/21 17:26, Max Reitz wrote:
Hi,
I’ve run into trouble with Vladimir’s async backup series on MacOS,
namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
Turns out this is because MacOS (-xcode) uses coroutine-sigaltstack,
when I us
On 01/20/21 17:26, Max Reitz wrote:
> Hi,
>
> I’ve run into trouble with Vladimir’s async backup series on MacOS,
> namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
>
> Turns out this is because MacOS (-xcode) uses coroutine-sigaltstack,
> when I use this on Linux, I get the s
On 1/20/21 10:26 AM, Max Reitz wrote:
> Hi,
>
> I’ve run into trouble with Vladimir’s async backup series on MacOS,
> namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
>
> Turns out this is because MacOS (-xcode) uses coroutine-sigaltstack,
> when I use this on Linux, I get the
On 20/01/21 17:26, Max Reitz wrote:
Now, this all seems obvious to me, but I’m wondering... If
coroutine-sigaltstack really couldn’t create coroutines concurrently,
why wouldn’t we have noticed before? I mean, this new backup case
is kind of a stress test, yes, but surely we would have seen t
Hi,
I’ve run into trouble with Vladimir’s async backup series on MacOS,
namely that iotest 256 fails with qemu exiting because of a SIGUSR2.
Turns out this is because MacOS (-xcode) uses coroutine-sigaltstack,
when I use this on Linux, I get the same error.
(You can find the series applied
26 matches
Mail list logo
