qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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