[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH-for-7.0 v3 2/2] ui/cocoa: run qemu_init in the main threa
From: |
Akihiko Odaki |
Subject: |
Re: [RFC PATCH-for-7.0 v3 2/2] ui/cocoa: run qemu_init in the main thread |
Date: |
Thu, 17 Mar 2022 21:51:45 +0900 |
On Thu, Mar 17, 2022 at 8:57 PM Philippe Mathieu-Daudé
<philippe.mathieu.daude@gmail.com> wrote:
>
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> Simplify the initialization dance by running qemu_init() in the main
> thread before the Cocoa event loop starts. The cocoa_display_init()
> code that is post-applicationDidFinishLaunching: moves to the
> application delegate itself, and the secondary thread only runs
> the rest of qemu_main(), namely qemu_main_loop() and qemu_cleanup().
>
> This fixes a case where addRemovableDevicesMenuItems() calls
> qmp_query_block() while expecting the main thread to still hold
> the BQL. The newly-introduced assertions in the block layer
> complain about this.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Message-Id: <20220307151004.578069-1-pbonzini@redhat.com>
> [PMD: Fixed trivial build failures & rebased]
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> softmmu/main.c | 12 +++---
> ui/cocoa.m | 114 ++++++++++++++++++++-----------------------------
> 2 files changed, 54 insertions(+), 72 deletions(-)
The following lines which will be out-dated.
> /*
> * Create the menu entries which depend on QEMU state (for consoles
> * and removeable devices). These make calls back into QEMU functions,
> * which is OK because at this point we know that the second thread
> * holds the iothread lock and is synchronously waiting for us to
> * finish.
> */
Regards,
Akihiko Odaki