From 517099e65de1e2ad3d0f33d3c4a7a71f8728279c Mon Sep 17 00:00:00 2001
From: Elisey <elisey.konstantinov@gmail.com>
Date: Mon, 23 Mar 2026 16:02:45 +0100
Subject: [PATCH] build: prefer sigaltstack over ucontext on Linux

sigaltstack coroutine backend is more stable on some Linux
configurations, while ucontext causes boot failures for certain
PPC Mac OS X guests (issue #3276).

Select sigaltstack first when available, keeping ucontext as fallback
until the underlying issue is resolved.

Signed-off-by: Elisey Konstantinov <elisey.konstantinov@gmail.com>
---
 meson.build | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index ab3e97eb9f..742655e007 100644
--- a/meson.build
+++ b/meson.build
@@ -505,10 +505,12 @@ if host_os == 'windows'
 elif host_os == 'emscripten'
   supported_backends += ['wasm']
 else
+  # FIXME: This is a temporary workaround!
+  # SigAltStack is in higher priority to fix #3276
+  supported_backends += ['sigaltstack']
   if host_os != 'darwin' and cc.links(ucontext_probe)
     supported_backends += ['ucontext']
   endif
-  supported_backends += ['sigaltstack']
 endif
 
 if coroutine_backend == 'auto'
-- 
2.50.1 (Apple Git-155)

On 4/24/26 09:19, Elisey Konstantinov wrote:
>  From 517099e65de1e2ad3d0f33d3c4a7a71f8728279c Mon Sep 17 00:00:00 2001
> From: Elisey <elisey.konstantinov@gmail.com>
> Date: Mon, 23 Mar 2026 16:02:45 +0100
> Subject: [PATCH] build: prefer sigaltstack over ucontext on Linux
> 
> sigaltstack coroutine backend is more stable on some Linux
> configurations, while ucontext causes boot failures for certain
> PPC Mac OS X guests (issue #3276).
> 
> Select sigaltstack first when available, keeping ucontext as fallback
> until the underlying issue is resolved.
> 
> Signed-off-by: Elisey Konstantinov <elisey.konstantinov@gmail.com>

I have never really liked using ucontext because we are only using it 
for setup and then switching to sigsetjmp/siglongjmp.  sigaltstack is 
not much better however.  I agree with others that for example the mutex 
could be masking the bug.

Many years ago I wrote an assembly-language coroutine backend:

https://patchew.org/QEMU/20190504120528.6389-1-pbonzini@redhat.com/

Perhaps you can try to resurrect it, even just for x86 to see if it 
fixes your issue?  This is the relevant patch:

https://patchew.org/QEMU/20190504120528.6389-4-pbonzini@redhat.com/mbox

and you only need util/coroutine-asm.c + simple changes to meson.build 
similar to the ones you have already made.

Note that you'll also have to add something like

diff --git a/meson.build b/meson.build
index 2bc2bd4d7bf..3a13da8a08d 100644
--- a/meson.build
+++ b/meson.build
@@ -391,6 +391,7 @@ qemu_isa_flags = []

  # Pick x86-64 baseline version
  if host_arch == 'x86_64'
+  qemu_isa_flags += ['-mno-red-zone']
    if get_option('x86_version') == '0'
      error('x86_64-v1 required for x86-64 hosts')
    endif

to meson.build (not optimal but simple).

Paolo

On Fri, Apr 24, 2026 at 11:19:39AM +0300, Elisey Konstantinov wrote:
> From 517099e65de1e2ad3d0f33d3c4a7a71f8728279c Mon Sep 17 00:00:00 2001
> From: Elisey <elisey.konstantinov@gmail.com>
> Date: Mon, 23 Mar 2026 16:02:45 +0100
> Subject: [PATCH] build: prefer sigaltstack over ucontext on Linux
> 
> sigaltstack coroutine backend is more stable on some Linux
> configurations, while ucontext causes boot failures for certain
> PPC Mac OS X guests (issue #3276).
> Select sigaltstack first when available, keeping ucontext as fallback
> until the underlying issue is resolved.

IMHO there needs to be a greater investigation in to why ucontext
would be demonstrating the failure. ucontext has been the default
on Linux for QEMU for decades without significant issues, so my
concern is that switching to sigaltstack is not fixing the root
cause of the bug you see, just masking it by luck.

The choice of coroutine backend can also be performance sensitive
and so changing it is something that would need to also bring
along performance benchmark data to illustrate the likely impact
of the change.

> 
> Signed-off-by: Elisey Konstantinov <elisey.konstantinov@gmail.com>
> ---
>  meson.build | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index ab3e97eb9f..742655e007 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -505,10 +505,12 @@ if host_os == 'windows'
>  elif host_os == 'emscripten'
>    supported_backends += ['wasm']
>  else
> +  # FIXME: This is a temporary workaround!
> +  # SigAltStack is in higher priority to fix #3276
> +  supported_backends += ['sigaltstack']
>    if host_os != 'darwin' and cc.links(ucontext_probe)
>      supported_backends += ['ucontext']
>    endif
> -  supported_backends += ['sigaltstack']
>  endif
>  
>  if coroutine_backend == 'auto'
> -- 
> 2.50.1 (Apple Git-155)
>

I completely agree, but in my opinion, investigating UContext will take a considerable amount of time, which is why I took the liberty of proposing this patch; in the commit message, I actually mention that this is merely a “temporary  workaround”

So, I suggest:
- Merging the patch into the mainstream for the convenience of users (as, from what I’ve observed, SigAltStack is coping quite well with the task, at least for now...)
- Whilst leaving #3276 open for the time being and continuing the UContext diagnostics there
- And accordingly, as soon as UContext is fully functional, we can switch QEMU back from SigAltStack

Also the another arrangement is to use UContext ONLY if PPC is in the build targets, but I am unable to do this, as my knowledge of Meson is insufficient for such a task; nevertheless, I would be grateful for any assistance :)

P. S. Anticipating such a reaction, I DELIBERATELY did not include “Resolves” in the patch notes, so I am fully aware of all the proposed precautions

On Fri, Apr 24, 2026 at 12:19:19PM +0300, Elisey Konstantinov wrote:
> I completely agree, but in my opinion, investigating UContext will take a considerable amount of time, which is why I took the liberty of proposing this patch; in the commit message, I actually mention that this is merely a “temporary  workaround”
> 
> So, I suggest:
> - Merging the patch into the mainstream for the convenience of users (as, from what I’ve observed, SigAltStack is coping quite well with the task, at least for now...)
> - Whilst leaving #3276 open for the time being and continuing the UContext diagnostics there
> - And accordingly, as soon as UContext is fully functional, we can switch QEMU back from SigAltStack
> 
> Also the another arrangement is to use UContext ONLY if PPC is in the build targets, but I am unable to do this, as my knowledge of Meson is insufficient for such a task; nevertheless, I would be grateful for any assistance :)
> 
> P. S. Anticipating such a reaction, I DELIBERATELY did not include “Resolves” in the patch notes, so I am fully aware of all the proposed precautions

PPC MacOS guest is such a niche use case, that I don't see a compelling
reason to make such a change in git until the ticket has been fully
investigated and the problem root caused.

I understand it’s a niche use case, however, “niche” doesn't mean “broken”
Currently, QEMU advertises support for PPC Mac OS X guests, but it doesn’t work on Linux
for certain versions
My patch fixes this breakage with a 3-line change, proven to work

If the root cause in UContext takes months to fix, will you leave the feature broken for all Linux users that long?
Can we apply this workaround to unblock users now, and continue the investigation in the issue tracker?

If not, what is the official status of PPC Mac OS X support in QEMU?

P. S.
	For example, SigAltStack is the only one way to use QEMU on macOS, and it works.. pretty good
	To be clear, only Linux and maybe BSD (which I can’t test, see details in the issue) works on UContext by the meantime...

On Fri, 24 Apr 2026 at 12:32, Elisey Konstantinov
<elisey.konstantinov@gmail.com> wrote:
>
> I understand it’s a niche use case, however, “niche” doesn't mean “broken”
> Currently, QEMU advertises support for PPC Mac OS X guests, but it doesn’t work on Linux
> for certain versions
> My patch fixes this breakage with a 3-line change, proven to work
>
> If the root cause in UContext takes months to fix, will you leave the feature broken for all Linux users that long?
> Can we apply this workaround to unblock users now, and continue the investigation in the issue tracker?

QEMU covers many more use cases than PPC macos emulation.
As Daniel says, this is very niche. It's almost certainly the
case that your proposed change is merely hiding an actual bug.
The coroutine backend is a fundamental part of how low level
parts of QEMU like the block backend work, which are heavily
relied on where QEMU is used as a virtual machine setup with
KVM and other accelerators. Changing the default here affects
a great many of our users. We should not do that only because
it happens to mask a bug somewhere in PPC emulation for
a particular guest OS.

If this was a workaround that affected only PPC and was at least
obviously a change to a PPC-specific part of QEMU like a particular
device model, we might take it. (Though even there we might say "no,
find the actual cause"; workarounds once accepted have a tendency
to stick around way longer than they ought to as people forget
whether and when they can be removed later). For a workaround which
affects every QEMU user including all the performance-sensitive
VM use cases, the answer is a clear "no".

> If not, what is the official status of PPC Mac OS X support in QEMU?

The "New World" and "Old World" machines are listed in our
MAINTAINERS file as "Odd Fixes", which means:

"It has a maintainer but they don't have time to do
 much other than throw the odd patch in."

In other words, there is no active development work ongoing,
and nobody with time and interest to investigate complex bugs.
If it happens to work for people, that's great. If it doesn't
work and somebody proposes a patch then we can review the patch
(as we have done for this one). If it doesn't work and nobody
proposes a satisfactory patch then it will likely remain broken.

thanks
-- PMM

On 24/04/2026 12:51, Peter Maydell wrote:

> The "New World" and "Old World" machines are listed in our
> MAINTAINERS file as "Odd Fixes", which means:
> 
> "It has a maintainer but they don't have time to do
>   much other than throw the odd patch in."
> 
> In other words, there is no active development work ongoing,
> and nobody with time and interest to investigate complex bugs.
> If it happens to work for people, that's great. If it doesn't
> work and somebody proposes a patch then we can review the patch
> (as we have done for this one). If it doesn't work and nobody
> proposes a satisfactory patch then it will likely remain broken.

I'm around to do various small bits and pieces, but at least for the short term it's 
fairly hard to find the extended time that bugs like these require.

Note that MacOS X before 10.2 (including MacOS 9) appear to be timing sensitive to 
the CUDA interrupts, so that might be another explanation. You could try 
experimenting with increasing the delay at 
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/misc/macio/cuda.c?ref_type=heads#L537 
to see if that helps?


ATB,

Mark.

Thank you very much, I’ll definitely give it a go, but I doubt that CUDA timing durations work differently across different backends, so I’m not holding out much hope
Although it would, of course, be great if that were the problem

Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:

> On 24/04/2026 12:51, Peter Maydell wrote:
>
>> The "New World" and "Old World" machines are listed in our
>> MAINTAINERS file as "Odd Fixes", which means:
>> 
>> "It has a maintainer but they don't have time to do
>>   much other than throw the odd patch in."
>> 
>> In other words, there is no active development work ongoing,
>> and nobody with time and interest to investigate complex bugs.
>> If it happens to work for people, that's great. If it doesn't
>> work and somebody proposes a patch then we can review the patch
>> (as we have done for this one). If it doesn't work and nobody
>> proposes a satisfactory patch then it will likely remain broken.
>
> I'm around to do various small bits and pieces, but at least for the short term it's 
> fairly hard to find the extended time that bugs like these require.
>
> Note that MacOS X before 10.2 (including MacOS 9) appear to be timing sensitive to 
> the CUDA interrupts, so that might be another explanation. You could try 
> experimenting with increasing the delay at 
> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/misc/macio/cuda.c?ref_type=heads#L537 
> to see if that helps?
>

Hi, just to let you all know I cannot reproduce this.

MacOS X boots past the initial screen, the installer comes up and
clicking around works fine. With both QEMU 10.0.0 and current master.

Oh, thanks for the feedback, however, could you please describe the environment you’re using?

Elisey Konstantinov <elisey.konstantinov@gmail.com> writes:

> Oh, thanks for the feedback, however, could you please describe the environment you’re using?

x86_64 host running Linux kernel 6.4.0. QEMU configured with:

../configure
--target-list=x86_64-softmmu,aarch64-softmmu,ppc64-softmmu,ppc-softmmu,s390x-softmmu,riscv64-softmmu,aarch64-linux-user,mips64-softmmu
--disable-plugins --enable-modules --enable-werror --enable-debug --disable-docs

QEMU cmdline:

qemu-system-ppc -machine mac99 -boot d -d guest_errors,unimp,cpu_reset
-cdrom osx_100_4k78_install.iso -prom-env "boot-args=-v"

Connecting via VNC shows the machine runs up to and past the point shown
in the screenshot posted as the working example in:
https://gitlab.com/qemu-project/qemu/-/work_items/3276#note_3105980116

Clicking around, the VM seems functional.

(tried to stitch the thread back together)

Elisey Konstantinov <elisey.konstantinov@gmail.com> writes:

> Fabiano Rosas <farosas@suse.de> writes:
>
>> Elisey Konstantinov <elisey.konstantinov@gmail.com> writes:
>>
>>> Oh, thanks for the feedback, however, could you please describe the environment you’re using?
>>
>> x86_64 host running Linux kernel 6.4.0. QEMU configured with:
>>
>> ../configure
>> --target-list=x86_64-softmmu,aarch64-softmmu,ppc64-softmmu,ppc-softmmu,s390x-softmmu,riscv64-softmmu,aarch64-linux-user,mips64-softmmu
>> --disable-plugins --enable-modules --enable-werror --enable-debug --disable-docs
>>
>> QEMU cmdline:
>>
>> qemu-system-ppc -machine mac99 -boot d -d guest_errors,unimp,cpu_reset
>> -cdrom osx_100_4k78_install.iso -prom-env "boot-args=-v"
>>
>> Connecting via VNC shows the machine runs up to and past the point shown
>> in the screenshot posted as the working example in:
>> https://gitlab.com/qemu-project/qemu/-/work_items/3276#note_3105980116
>>
>> Clicking around, the VM seems functional.
>
> Yeah, this sounds weird, could you please test on the old distribution,
> like Debian 12?See three of my latest messages in the main thread for
> more information

Sorry, I don't have the means to test this on Debian 12. It's not clear
from the thread, have you reproduced the issue using the HEAD of QEMU's
master branch? If so, then I think the best we could do is go back to
the original issue[1] on Gitlab and continue the investigation.

From the information you posted there, the execution should have gotten
past the happy mac screen. You could try running with -prom-env
"boot-args=-v" as I did above and see if it gives you any logging past
that screen. Post a screenshot of your VNC session showing those logs.

1- https://gitlab.com/qemu-project/qemu/-/work_items/3276