1. 17 Nov, 2014 1 commit
  2. 09 Oct, 2014 2 commits
  3. 04 Oct, 2014 6 commits
  4. 20 Sep, 2014 1 commit
  5. 16 Sep, 2014 4 commits
  6. 05 Sep, 2014 1 commit
  7. 15 Aug, 2014 2 commits
  8. 06 Aug, 2014 1 commit
    • Paolo Bonzini's avatar
      backends: Introduce chr-testdev · 5692399f
      Paolo Bonzini authored
      From: Paolo Bonzini <pbonzini@redhat.com>
      chr-testdev enables a virtio serial channel to be used for guest
      initiated qemu exits. hw/misc/debugexit already enables guest
      initiated qemu exits, but only for PC targets. chr-testdev supports
      any virtio-capable target. kvm-unit-tests/arm is already making use
      of this backend.
      Currently there is a single command implemented, "q".  It takes a
      (prefix) argument for the exit code, thus an exit is implemented by
      writing, e.g. "1q", to the virtio-serial port.
      It can be used as:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtserialport,chardev=ctd -chardev testdev,id=ctd
      or, use:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtconsole,chardev=ctd -chardev testdev,id=ctd
      to bind it to virtio-serial port0.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  9. 25 Jul, 2014 1 commit
  10. 14 Jul, 2014 1 commit
    • Paolo Bonzini's avatar
      qemu-char: fix deadlock with "-monitor pty" · 7b3621f4
      Paolo Bonzini authored
      qemu_chr_be_generic_open cannot be called with the write lock taken,
      because it calls client code that may call qemu_chr_fe_write.  This
      actually happens for the monitor:
          0x00007ffff27dbf79 in __GI_raise (sig=sig@entry=6)
          0x00007ffff27df388 in __GI_abort ()
          0x00005555555ef489 in error_exit (err=<optimized out>, msg=msg@entry=0x5555559796d0 <__func__.5959> "qemu_mutex_lock")
          0x00005555558f9080 in qemu_mutex_lock (mutex=mutex@entry=0x555556248a30)
          0x0000555555713936 in qemu_chr_fe_write (s=0x555556248a30, buf=buf@entry=0x5555563d8870 "QEMU 2.0.90 monitor - type 'help' for more information\r\n", len=56)
          0x00005555556217fd in monitor_flush_locked (mon=mon@entry=0x555556251fd0)
          0x0000555555621a12 in monitor_flush_locked (mon=0x555556251fd0)
          monitor_puts (mon=mon@entry=0x555556251fd0, str=0x55555634bfa7 "", str@entry=0x55555634bf70 "QEMU 2.0.90 monitor - type 'help' for more information\n")
          0x0000555555624359 in monitor_vprintf (mon=0x555556251fd0, fmt=<optimized out>, ap=<optimized out>)
          0x0000555555624414 in monitor_printf (mon=<optimized out>, fmt=fmt@entry=0x5555559105a0 "QEMU %s monitor - type 'help' for more information\n")
          0x0000555555629806 in monitor_event (opaque=0x555556251fd0, event=<optimized out>)
          0x000055555571343c in qemu_chr_be_generic_open (s=0x555556248a30)
      To avoid this, defer the call to an idle callback, which will be
      called as soon as the main loop is re-entered.  In order to simplify
      the cleanup and do it in one place only, change pty_chr_close to
      call pty_chr_state.
      To reproduce, run with "-monitor pty", then try to read from the
      slave /dev/pts/FOO that it creates.
      Fixes: 9005b2a7Reported-by: default avatarLi Liang <liangx.z.li@intel.com>
      Reviewed-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  11. 06 Jul, 2014 2 commits
  12. 27 Jun, 2014 1 commit
  13. 26 Jun, 2014 2 commits
  14. 23 Jun, 2014 7 commits
  15. 19 Jun, 2014 4 commits
  16. 13 Jun, 2014 1 commit
    • David Marchand's avatar
      char: fix avail_connections init in qemu_chr_open_eventfd() · e9d21c43
      David Marchand authored
      When trying to use a ivshmem server with qemu, ivshmem init code tries to
      create a CharDriverState object for each eventfd retrieved from the server.
      To create this object, a call to qemu_chr_open_eventfd() is done.
      Right after this, before adding a frontend, qemu_chr_fe_claim_no_fail() is
      qemu_chr_open_eventfd() does not set avail_connections to 1, so no frontend can
      be associated because qemu_chr_fe_claim_no_fail() makes qemu stop right away.
      This problem comes from 456d6069
      "qemu-char: Call fe_claim / fe_release when not using qdev chr properties".
      Fix this, by setting avail_connections to 1 in qemu_chr_open_eventfd().
      Signed-off-by: default avatarDavid Marchand <david.marchand@6wind.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
  17. 11 Jun, 2014 1 commit
  18. 21 May, 2014 2 commits