1. 23 Dec, 2013 1 commit
  2. 16 Dec, 2013 1 commit
  3. 05 Oct, 2013 1 commit
  4. 01 Oct, 2013 1 commit
  5. 12 Sep, 2013 1 commit
    • Gerd Hoffmann's avatar
      chardev: fix pty_chr_timer · b0d768c3
      Gerd Hoffmann authored
      pty_chr_timer first calls pty_chr_update_read_handler(), then clears
      timer_tag (because it is a one-shot timer).   This is the wrong order
      though.  pty_chr_update_read_handler might re-arm time timer, and the
      new timer_tag gets overwitten in that case.
      This leads to crashes when unplugging a pty chardev:  pty_chr_close
      thinks no timer is running -> timer isn't canceled -> pty_chr_timer gets
      called with stale CharDevState -> BOOM.
      This patch fixes the ordering.
      Kill the pointless goto while being at it.
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
  6. 05 Sep, 2013 3 commits
  7. 22 Aug, 2013 1 commit
  8. 20 Aug, 2013 1 commit
  9. 13 Aug, 2013 1 commit
    • James Hogan's avatar
      qemu-char: fix infinite recursion connecting to monitor pty · 3a3567d3
      James Hogan authored
      Since commit bd5c51ee (qemu-char: don't issue CHR_EVENT_OPEN in a BH), an
      infinite recursion occurs when putting the monitor on a pty (-monitor
      pty) and connecting a terminal to the slave port.
      This is because of the qemu_chr_be_event(s, CHR_EVENT_OPENED) added to
      qemu_chr_be_generic_open(). This event is captured by monitor_event()
      which prints a welcome message to the character device. The flush of
      that welcome message retriggers another open event in pty_chr_state()
      because it checks s->connected, but only sets it to 1 after calling
      I've fixed this by setting s->connected = 1 before the call to
      qemu_chr_be_generic_open() instead of after, so that the recursive
      pty_chr_state() doesn't call it again.
      An example snippet of repeating backtrace:
       #107486 0x007aec58 in monitor_flush (mon=0xf418b0) at qemu/monitor.c:288
       #107487 0x007aee7c in monitor_puts (mon=0xf418b0, str=0x1176d07 "") at qemu/monitor.c:322
       #107488 0x007aef20 in monitor_vprintf (mon=0xf418b0, fmt=0x8d4820 "QEMU %s monitor - type 'help' for more information\n",
           ap=0x7f432be0) at qemu/monitor.c:339
       #107489 0x007aefac in monitor_printf (mon=0xf418b0, fmt=0x8d4820 "QEMU %s monitor - type 'help' for more information\n")
           at qemu/monitor.c:347
       #107490 0x007ba4bc in monitor_event (opaque=0xf418b0, event=2) at qemu/monitor.c:4699
       #107491 0x00684c28 in qemu_chr_be_event (s=0xf37788, event=2) at qemu/qemu-char.c:108
       #107492 0x00684c70 in qemu_chr_be_generic_open (s=0xf37788) at qemu/qemu-char.c:113
       #107493 0x006880a4 in pty_chr_state (chr=0xf37788, connected=1) at qemu/qemu-char.c:1145
       #107494 0x00687fa4 in pty_chr_update_read_handler (chr=0xf37788) at qemu/qemu-char.c:1121
       #107495 0x00687c9c in pty_chr_write (chr=0xf37788, buf=0x70b3c008 <Address 0x70b3c008 out of bounds>, len=538720)
           at qemu/qemu-char.c:1063
       #107496 0x00684cc4 in qemu_chr_fe_write (s=0xf37788, buf=0x70b3c008 <Address 0x70b3c008 out of bounds>, len=538720)
           at qemu/qemu-char.c:118
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Tested-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Message-id: 1375960178-10882-1-git-send-email-james.hogan@imgtec.com
      Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
      Cc: Anthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  10. 30 Jul, 2013 1 commit
    • Michael Roth's avatar
      chardev: fix CHR_EVENT_OPENED events for mux chardevs · 7b7ab18d
      Michael Roth authored
      As of bd5c51ee, chardevs no longer use
      bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
      semantics, we instead defer the CHR_EVENT_OPENED events toward the end
      of chardev initialization.
      For muxes, this isn't good enough, since a range of FEs must be able
      to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
      each FE will immediately print it's initial output (prompts, banners,
      etc.) just prior to us switching to the next FE as part of
      The is new and confusing behavior for users, as they'll see output for
      things like the HMP monitor, even though their the current mux focus
      may be a guest serial port with potentially no output.
      We fix this by further deferring CHR_EVENT_OPENED events for FEs
      associated with muxes until after machine init by flagging mux chardevs
      with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
      events until we explicitly set the mux as opened later.
      Currently, we must defer till after machine init since we potentially
      associate FEs with muxes as part of realize (for instance,
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  11. 29 Jul, 2013 3 commits
    • Markus Armbruster's avatar
      qapi: Rename ChardevBackend member "memory" to "ringbuf" · 3a1da42e
      Markus Armbruster authored
      Commit 1da48c65 called the new member "memory" after commit 3949e594
      standardized "ringbuf".  Rename for consistency.
      However, member name "memory" is visible in QMP since 1.5.  It's
      undocumented just like the driver name.  Keep it working anyway.
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Message-id: 1374849874-25531-4-git-send-email-armbru@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
    • Markus Armbruster's avatar
      qemu-char: Register ring buffer driver with correct name "ringbuf" · c11ed966
      Markus Armbruster authored
      The driver is new in 1.4, with the documented name "ringbuf".
      However, it's actual name is the completely undocumented "memory".
      Screwed up in commit 3949e594.  Fix code to match documentation.
      Keep the undocumented name working as an alias for compatibility.
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Message-id: 1374849874-25531-3-git-send-email-armbru@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
    • Markus Armbruster's avatar
      Revert "chardev: Make the name of memory device consistent" · 4f57378f
      Markus Armbruster authored
      This reverts commit 6a85e60c.
      Commit 51767e7c "qemu-char: Add new char backend CirMemCharDriver"
      introduced a memory ring buffer character device driver named
      "memory".  Commit 3949e594 "qemu-char: Saner naming of memchar stuff &
      doc fixes" changed the driver name to "ringbuf", along with a whole
      bunch of other names, with the following rationale:
          Naming is a mess.  The code calls the device driver
          CirMemCharDriver, the public API calls it "memory", "memchardev",
          or "memchar", and the special commands are named like
          "memchar-FOO".  "memory" is a particularly unfortunate choice,
          because there's another character device driver called
          MemoryDriver.  Moreover, the device's distinctive property is that
          it's a ring buffer, not that's in memory.
      This is what we released in 1.4.0.
      Unfortunately, the rename missed a critical instance of "memory": the
      actual driver name.  Thus, the new device could be used only by an
      entirely undocumented name.  The documented name did not work.
      Commit 6a85e60c fixes this by changing the documentation to match the
      code.  It also changes some, but not all related occurences of
      "ringbuf" to "memory".  Left alone are identifiers in C code, HMP and
      QMP commands.  The latter are external interface, so they can't be
      The result is an inconsistent mess.  Moreover, "memory" is a rotten
      name.  The device's distinctive property is that it's a ring buffer,
      not that's in memory.  User's don't care whether it's in RAM, flash,
      or carved into chocolate tablets by Oompa Loompas.
      Revert the commit.  Next commit will fix just the bug.
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Message-id: 1374849874-25531-2-git-send-email-armbru@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  12. 18 Jul, 2013 1 commit
  13. 10 Jul, 2013 1 commit
  14. 09 Jul, 2013 1 commit
  15. 28 Jun, 2013 9 commits
  16. 21 Jun, 2013 1 commit
  17. 14 Jun, 2013 1 commit
    • Michael Tokarev's avatar
      create qemu_openpty_raw() helper function and move it to a separate file · 4efeabbb
      Michael Tokarev authored
      In two places qemu uses openpty() which is very system-dependent,
      and in both places the pty is switched to raw mode as well.
      Make a wrapper function which does both steps, and move all the
      system-dependent complexity into a separate file, together
      with static/local implementations of openpty() and cfmakeraw()
      from qemu-char.c.
      It is in a separate file, not part of oslib-posix.c, because
      openpty() often resides in -lutil which is not linked to
      every program qemu builds.
      This change removes #including of <pty.h>, <termios.h>
      and other rather specific system headers out of qemu-common.h,
      which isn't a place for such specific headers really.
      This version has been verified to build correctly on Linux,
      OpenBSD, FreeBSD and OpenIndiana.  On the latter it lets qemu
      to be built with gtk gui which were not possible there due to
      missing openpty() and cfmakeraw().
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Tested-by: default avatarAndreas Färber <andreas.faerber@web.de>
  18. 11 Jun, 2013 1 commit
  19. 10 Jun, 2013 1 commit
    • Michael Roth's avatar
      qemu-char: don't issue CHR_EVENT_OPEN in a BH · bd5c51ee
      Michael Roth authored
      When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
      and it was issued as a bottom-half:
      Which we basically used to print out a greeting/prompt for the
      AFAICT the only reason this was ever done in a BH was because in
      some cases we'd modify the chr_write handler for a new chardev
      backend *after* the site where we issued the reset (see:
      At some point this event was renamed to CHR_EVENT_OPENED, and we've
      maintained the use of this BH ever since.
      However, due to 9f939df9, we schedule
      the BH via g_idle_add(), which is causing events to sometimes be
      delivered after we've already begun processing data from backends,
      leading to:
       known bugs:
          session negotation resets with OPENED event, in some cases this
          is causing new sessions to get sporadically reset
       potential bugs:
          can_read handler checks for dev->parser != NULL, which may be
          true if CLOSED BH has not been executed yet. In the past, OPENED
          quiesced outstanding CLOSED events prior to us reading client
          data. If it's delayed, our check may allow reads to occur even
          though we haven't processed the OPENED event yet, and when we
          do finally get the OPENED event, our state may get reset.
          can begin session before OPENED event is processed, leading to
          a spurious reset of the system and irq_levels
          may start a gdb session prior to the machine being paused
      To fix these, let's just drop the BH.
      Since the initial reasoning for using it still applies to an extent,
      work around that by deferring the delivery of CHR_EVENT_OPENED until
      after the chardevs have been fully initialized, toward the end of
      qmp_chardev_add() (or some cases, qemu_chr_new_from_opts()). This
      defers delivery long enough that we can be assured a CharDriverState
      is fully initialized before CHR_EVENT_OPENED is sent.
      Also, rather than requiring each chardev to do an explicit open, do it
      automatically, and allow the small few who don't desire such behavior to
      suppress the OPENED-on-init behavior by setting a 'explicit_be_open'
      We additionally add missing OPENED events for stdio backends on w32,
      which were previously not being issued, causing us to not recieve the
      banner and initial prompts for qmp/hmp.
      Reported-by: default avatarStefan Priebe <s.priebe@profihost.ag>
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Message-id: 1370636393-21044-1-git-send-email-mdroth@linux.vnet.ibm.com
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  20. 27 May, 2013 2 commits
  21. 22 May, 2013 3 commits
  22. 20 May, 2013 1 commit
  23. 14 May, 2013 1 commit
  24. 25 Apr, 2013 1 commit
    • Hans de Goede's avatar
      qemu-char: Set foo_tag = 0 when returning FALSE from callbacks · 79f20075
      Hans de Goede authored
      While reviewing some patches I found this problem where tcp_chr_accept
      does not clear listen_tag when returning FALSE, leading to a double
      g_source_remove of the underlying source. Not really a problem unless the id
      gets re-used in between, but still something we should fix.
      While at it I've also reviewed all the other code in qemu-char.c for
      similar problems and found that pty_chr_timer has the same problem.
      Cc: Anthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Message-id: 1366890782-10311-1-git-send-email-hdegoede@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  25. 22 Apr, 2013 1 commit
    • Paolo Bonzini's avatar
      qemu-char: do not operate on sources from finalize callbacks · 2b316774
      Paolo Bonzini authored
      Due to a glib bug, the finalize callback is called with the GMainContext
      lock held.  Thus, any operation on the context from the callback will
      cause recursive locking and a deadlock.  This happens, for example,
      when a client disconnects from a socket chardev.
      The fix for this is somewhat ugly, because we need to forego polymorphism
      and implement our own function to destroy IOWatchPoll sources.  The
      right thing to do here would be child sources, but we support older
      glib versions that do not have them.  Not coincidentially, glib developers
      found and fixed the deadlock as part of implementing child sources.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Tested-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
      Message-id: 1366385529-10329-5-git-send-email-pbonzini@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>