[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1675108] [NEW] Cocoa UI always crashes on startup

From: Alex Bennée
Subject: Re: [Qemu-devel] [Bug 1675108] [NEW] Cocoa UI always crashes on startup
Date: Thu, 23 Mar 2017 11:13:02 +0000
User-agent: mu4e 0.9.19; emacs 25.2.10

Peter Maydell <address@hidden> writes:

> On 22 March 2017 at 17:26, Brendan Shanks <address@hidden> wrote:
>> Public bug reported:
>> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure
>> graphic updates don't race with TCG vCPUs") causes the graphic update to
>> run on a non-main thread, which Cocoa is not happy with. It crashes
>> immediately after startup.
> Oops. Alex, we can't just run UI code on random threads like this.

Technically its not a random thread its the vCPU context (which ensures
the vCPU isn't updating while the display is being updated). But I guess
the Cocoa is limited to not being able to update from an arbitrary

There was a patch posted yesterday to ensure the BQL is held during the
deferred work but this doesn't look like that.

> Any ideas?

Hmm a quick Google seems to imply Cocoa is inflexible in its
requirements. You can try this ugly but untested patch (I don't have any
Macs handy):

modified   ui/console.c
@@ -1598,8 +1598,16 @@ static void dpy_refresh(DisplayState *s)
     QLIST_FOREACH(dcl, &s->listeners, next) {
         if (dcl->ops->dpy_refresh) {
             if (tcg_enabled()) {
+                qemu_mutex_unlock_iothread();
+                start_exclusive();
+                do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl));
+                end_exclusive();
+                qemu_mutex_lock_iothread();
                 async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh,
             } else {

Other than that I guess we need to bring forward the plans to "fixed the dirty 
races in display adapters"

> thanks
> -- PMM

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]