qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Yifan <me@yifanlu.com>
To: qemu-devel@nongnu.org
Subject: [Bug 1863023] [NEW] Deadlock in QXL
Date: Wed, 12 Feb 2020 21:47:10 -0000	[thread overview]
Message-ID: <158154403075.14879.10753031266357045514.malonedeb@soybean.canonical.com> (raw)

Public bug reported:

This is on qemu 4.2.0 OSX host, running fresh Windows 7 with SPICE guest
tools just installed.

Command line: `qemu-system-x86_64 -qmp tcp:localhost:4444,server,nowait
-smp cpus=2 -boot order=d -m 2048 -soundhw hda -drive
file=hda.img,if=ide,media=disk -spice port=5930,addr=127.0.0.1,disable-
ticketing,image-compression=off,playback-compression=off,streaming-
video=off -vga qxl -device rtl8139,netdev=net0 -netdev user,id=net0`

After the Windows logo, the screen is black. I dump the two vCPU
threads:

```
* thread #16
  * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e8d0, mutex=0x000000011120ba48, file="cpus-common.c", line=144) at qemu-thread-posix.c:173:11 [opt]
    frame #3: 0x0000000110926a59 qemu-system-x86_64`do_run_on_cpu(cpu=<unavailable>, func=<unavailable>, data=<unavailable>, mutex=0x000000011120ba48) at cpus-common.c:144:9 [opt]
    frame #4: 0x000000011080c50a qemu-system-x86_64`memory_region_snapshot_and_clear_dirty at memory.c:2595:5 [opt]
    frame #5: 0x000000011080c4d7 qemu-system-x86_64`memory_region_snapshot_and_clear_dirty(mr=<unavailable>, addr=0, size=2359296, client=<unavailable>) at memory.c:2107 [opt]
    frame #6: 0x0000000110849fe1 qemu-system-x86_64`vga_update_display [inlined] vga_draw_graphic(s=<unavailable>, full_update=0) at vga.c:1661:16 [opt]
    frame #7: 0x000000011084996a qemu-system-x86_64`vga_update_display(opaque=<unavailable>) at vga.c:1785 [opt]
    frame #8: 0x00000001109b261d qemu-system-x86_64`qxl_hard_reset(d=0x00007f84f8730000, loadvm=0) at qxl.c:1285:5 [opt]
    frame #9: 0x000000011080ac97 qemu-system-x86_64`memory_region_write_accessor(mr=0x00007f84f8741fb0, addr=5, value=<unavailable>, size=1, shift=<unavailable>, mask=<unavailable>, attrs=MemTxAttrs @ 0x000070000786d890) at memory.c:483:5 [opt]
    frame #10: 0x000000011080ab31 qemu-system-x86_64`memory_region_dispatch_write [inlined] access_with_adjusted_size(addr=<unavailable>, value=0x00000000015c6100, size=<unavailable>, access_size_min=<unavailable>, access_size_max=<unavailable>, access_fn=<unavailable>, mr=<unavailable>, attrs=<unavailable>) at memory.c:544:18 [opt]
    frame #11: 0x000000011080aafd qemu-system-x86_64`memory_region_dispatch_write(mr=<unavailable>, addr=<unavailable>, data=22831360, op=32644, attrs=MemTxAttrs @ 0x000070000786d8c0) at memory.c:1475 [opt]
    frame #12: 0x00000001107b080d qemu-system-x86_64`address_space_stb(as=<unavailable>, addr=<unavailable>, val=22831360, attrs=MemTxAttrs @ r12, result=0x0000000000000000) at memory_ldst.inc.c:378:13 [opt]
    frame #13: 0x0000000118570230

* thread #18
  * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e860, mutex=0x000000011121e818, file="cpus-common.c", line=196) at qemu-thread-posix.c:173:11 [opt]
    frame #3: 0x0000000110926c44 qemu-system-x86_64`start_exclusive at cpus-common.c:196:9 [opt]
    frame #4: 0x0000000110837c35 qemu-system-x86_64`cpu_exec_step_atomic(cpu=0x00007f8518290000) at cpu-exec.c:265:9 [opt]
    frame #5: 0x00000001107fcf95 qemu-system-x86_64`qemu_tcg_cpu_thread_fn(arg=0x00007f8518290000) at cpus.c:1799:17 [opt]
    frame #6: 0x0000000110bf911e qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:519:9 [opt]
    frame #7: 0x00007fff52466e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #8: 0x00007fff5246283b libsystem_pthread.dylib`thread_start + 15
```

Seems like thread #16 had a STB to QXL MMIO registers which caused it to
call `qxl_hard_reset` and eventually made its way to `do_run_on_cpu`
which waits for `qemu_work_cond`. The only way `qemu_work_cond` is set
is if one of the two vCPU executes the queued work at the end of the TCG
execution. Thread #16 is stuck waiting, so what about thread #18? Thread
#18 is waiting for `exclusive_cond` which is set once all the other CPUs
are done running (but thread #16 is waiting still). So classic deadlock.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1863023

Title:
  Deadlock in QXL

Status in QEMU:
  New

Bug description:
  This is on qemu 4.2.0 OSX host, running fresh Windows 7 with SPICE
  guest tools just installed.

  Command line: `qemu-system-x86_64 -qmp
  tcp:localhost:4444,server,nowait -smp cpus=2 -boot order=d -m 2048
  -soundhw hda -drive file=hda.img,if=ide,media=disk -spice
  port=5930,addr=127.0.0.1,disable-ticketing,image-compression=off
  ,playback-compression=off,streaming-video=off -vga qxl -device
  rtl8139,netdev=net0 -netdev user,id=net0`

  After the Windows logo, the screen is black. I dump the two vCPU
  threads:

  ```
  * thread #16
    * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
      frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701
      frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e8d0, mutex=0x000000011120ba48, file="cpus-common.c", line=144) at qemu-thread-posix.c:173:11 [opt]
      frame #3: 0x0000000110926a59 qemu-system-x86_64`do_run_on_cpu(cpu=<unavailable>, func=<unavailable>, data=<unavailable>, mutex=0x000000011120ba48) at cpus-common.c:144:9 [opt]
      frame #4: 0x000000011080c50a qemu-system-x86_64`memory_region_snapshot_and_clear_dirty at memory.c:2595:5 [opt]
      frame #5: 0x000000011080c4d7 qemu-system-x86_64`memory_region_snapshot_and_clear_dirty(mr=<unavailable>, addr=0, size=2359296, client=<unavailable>) at memory.c:2107 [opt]
      frame #6: 0x0000000110849fe1 qemu-system-x86_64`vga_update_display [inlined] vga_draw_graphic(s=<unavailable>, full_update=0) at vga.c:1661:16 [opt]
      frame #7: 0x000000011084996a qemu-system-x86_64`vga_update_display(opaque=<unavailable>) at vga.c:1785 [opt]
      frame #8: 0x00000001109b261d qemu-system-x86_64`qxl_hard_reset(d=0x00007f84f8730000, loadvm=0) at qxl.c:1285:5 [opt]
      frame #9: 0x000000011080ac97 qemu-system-x86_64`memory_region_write_accessor(mr=0x00007f84f8741fb0, addr=5, value=<unavailable>, size=1, shift=<unavailable>, mask=<unavailable>, attrs=MemTxAttrs @ 0x000070000786d890) at memory.c:483:5 [opt]
      frame #10: 0x000000011080ab31 qemu-system-x86_64`memory_region_dispatch_write [inlined] access_with_adjusted_size(addr=<unavailable>, value=0x00000000015c6100, size=<unavailable>, access_size_min=<unavailable>, access_size_max=<unavailable>, access_fn=<unavailable>, mr=<unavailable>, attrs=<unavailable>) at memory.c:544:18 [opt]
      frame #11: 0x000000011080aafd qemu-system-x86_64`memory_region_dispatch_write(mr=<unavailable>, addr=<unavailable>, data=22831360, op=32644, attrs=MemTxAttrs @ 0x000070000786d8c0) at memory.c:1475 [opt]
      frame #12: 0x00000001107b080d qemu-system-x86_64`address_space_stb(as=<unavailable>, addr=<unavailable>, val=22831360, attrs=MemTxAttrs @ r12, result=0x0000000000000000) at memory_ldst.inc.c:378:13 [opt]
      frame #13: 0x0000000118570230

  * thread #18
    * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
      frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701
      frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e860, mutex=0x000000011121e818, file="cpus-common.c", line=196) at qemu-thread-posix.c:173:11 [opt]
      frame #3: 0x0000000110926c44 qemu-system-x86_64`start_exclusive at cpus-common.c:196:9 [opt]
      frame #4: 0x0000000110837c35 qemu-system-x86_64`cpu_exec_step_atomic(cpu=0x00007f8518290000) at cpu-exec.c:265:9 [opt]
      frame #5: 0x00000001107fcf95 qemu-system-x86_64`qemu_tcg_cpu_thread_fn(arg=0x00007f8518290000) at cpus.c:1799:17 [opt]
      frame #6: 0x0000000110bf911e qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:519:9 [opt]
      frame #7: 0x00007fff52466e65 libsystem_pthread.dylib`_pthread_start + 148
      frame #8: 0x00007fff5246283b libsystem_pthread.dylib`thread_start + 15
  ```

  Seems like thread #16 had a STB to QXL MMIO registers which caused it
  to call `qxl_hard_reset` and eventually made its way to
  `do_run_on_cpu` which waits for `qemu_work_cond`. The only way
  `qemu_work_cond` is set is if one of the two vCPU executes the queued
  work at the end of the TCG execution. Thread #16 is stuck waiting, so
  what about thread #18? Thread #18 is waiting for `exclusive_cond`
  which is set once all the other CPUs are done running (but thread #16
  is waiting still). So classic deadlock.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1863023/+subscriptions


             reply	other threads:[~2020-02-13  2:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 21:47 Yifan [this message]
2020-03-06 12:32 ` [Bug 1863023] Re: Deadlock in QXL Gerd Hoffmann
2020-03-06 13:27 ` Alex Bennée
2021-05-05 15:16 ` Thomas Huth
2021-07-05  4:17 ` Launchpad Bug Tracker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=158154403075.14879.10753031266357045514.malonedeb@soybean.canonical.com \
    --to=me@yifanlu.com \
    --cc=1863023@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).