Peter Maydell <peter.mayd...@linaro.org> writes:
> On 22 March 2017 at 17:26, Brendan Shanks <bren...@bslabs.net> 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
thread?
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()) {
+#ifdef CONFIG_COCOA
+ qemu_mutex_unlock_iothread();
+ start_exclusive();
+ do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl));
+ end_exclusive();
+ qemu_mutex_lock_iothread();
+#else
async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh,
RUN_ON_CPU_HOST_PTR(dcl));
+#endif
} else {
dcl->ops->dpy_refresh(dcl);
}
Other than that I guess we need to bring forward the plans to "fixed the dirty
tracking
races in display adapters"
>
> thanks
> -- PMM
--
Alex Bennée
