mirror of
https://gitlab.com/qemu-project/qemu
synced 2024-11-05 20:35:44 +00:00
ui/console: ensure do_safe_dpy_refresh holds BQL
I missed the fact that when an exclusive work item runs it drops the BQL to ensure all no vCPUs are stuck waiting for it, hence causing a deadlock. However the actual helper needs to take the BQL especially as we'll be messing with device emulation bits during the update which all assume BQL is held. We make a minor cpu_reloading_memory_map which must try and unlock the RCU if we are actually outside the running context. Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
This commit is contained in:
parent
95992b674c
commit
8539093919
2 changed files with 3 additions and 1 deletions
|
@ -35,7 +35,7 @@ void cpu_loop_exit_noexc(CPUState *cpu)
|
|||
#if defined(CONFIG_SOFTMMU)
|
||||
void cpu_reloading_memory_map(void)
|
||||
{
|
||||
if (qemu_in_vcpu_thread()) {
|
||||
if (qemu_in_vcpu_thread() && current_cpu->running) {
|
||||
/* The guest can in theory prolong the RCU critical section as long
|
||||
* as it feels like. The major problem with this is that because it
|
||||
* can do multiple reconfigurations of the memory map within the
|
||||
|
|
|
@ -1586,7 +1586,9 @@ bool dpy_gfx_check_format(QemuConsole *con,
|
|||
static void do_safe_dpy_refresh(CPUState *cpu, run_on_cpu_data opaque)
|
||||
{
|
||||
DisplayChangeListener *dcl = opaque.host_ptr;
|
||||
qemu_mutex_lock_iothread();
|
||||
dcl->ops->dpy_refresh(dcl);
|
||||
qemu_mutex_unlock_iothread();
|
||||
}
|
||||
|
||||
static void dpy_refresh(DisplayState *s)
|
||||
|
|
Loading…
Reference in a new issue