Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 14 8月, 2013 1 次提交
    • J
      qemu-char: fix infinite recursion connecting to monitor pty · 3a3567d3
      由 James Hogan 提交于 
      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
qemu_chr_be_generic_open().

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: NJames Hogan <james.hogan@imgtec.com>
Tested-by: NMichael 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: NAnthony Liguori <aliguori@us.ibm.com>
      3a3567d3
  3. 31 7月, 2013 1 次提交
    • M
      chardev: fix CHR_EVENT_OPENED events for mux chardevs · 7b7ab18d
      由 Michael Roth 提交于 
      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
initialization.

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,
serial_isa_realizefn).
Signed-off-by: NMichael 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: NAnthony Liguori <aliguori@us.ibm.com>
      7b7ab18d
  5. 29 7月, 2013 3 次提交
    • M
      qapi: Rename ChardevBackend member "memory" to "ringbuf" · 3a1da42e
      由 Markus Armbruster 提交于 
      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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-4-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      3a1da42e
    • M
      qemu-char: Register ring buffer driver with correct name "ringbuf" · c11ed966
      由 Markus Armbruster 提交于 
      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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-3-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      c11ed966
    • M
      Revert "chardev: Make the name of memory device consistent" · 4f57378f
      由 Markus Armbruster 提交于 
      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.
Bummer.

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
changed.

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-2-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4f57378f
  7. 19 7月, 2013 1 次提交
  9. 11 7月, 2013 1 次提交
  11. 10 7月, 2013 1 次提交
  13. 29 6月, 2013 9 次提交
  15. 22 6月, 2013 1 次提交
  17. 14 6月, 2013 1 次提交
    • M
      create qemu_openpty_raw() helper function and move it to a separate file · 4efeabbb
      由 Michael Tokarev 提交于 
      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: NMichael Tokarev <mjt@tls.msk.ru>
Tested-by: NAndreas Färber <andreas.faerber@web.de>
      4efeabbb
  19. 12 6月, 2013 1 次提交
  21. 11 6月, 2013 1 次提交
    • M
      qemu-char: don't issue CHR_EVENT_OPEN in a BH · bd5c51ee
      由 Michael Roth 提交于 
      When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
and it was issued as a bottom-half:

86e94dea

Which we basically used to print out a greeting/prompt for the
monitor.

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:
86e94d:qemu_chr_open_stdio())

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:

  QMP:
    session negotation resets with OPENED event, in some cases this
    is causing new sessions to get sporadically reset

 potential bugs:

  hw/usb/redirect.c:
    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.

  qtest.c:
    can begin session before OPENED event is processed, leading to
    a spurious reset of the system and irq_levels

  gdbstub.c:
    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'
flag.

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: NStefan Priebe <s.priebe@profihost.ag>
Signed-off-by: NMichael 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: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      bd5c51ee
  23. 27 5月, 2013 2 次提交
  25. 22 5月, 2013 3 次提交
  27. 20 5月, 2013 1 次提交
  29. 14 5月, 2013 1 次提交
  31. 26 4月, 2013 1 次提交
    • H
      qemu-char: Set foo_tag = 0 when returning FALSE from callbacks · 79f20075
      由 Hans de Goede 提交于 
      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: NHans de Goede <hdegoede@redhat.com>
Message-id: 1366890782-10311-1-git-send-email-hdegoede@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      79f20075
  33. 22 4月, 2013 4 次提交
  35. 16 4月, 2013 1 次提交
  37. 15 4月, 2013 1 次提交
    • P
      qemu-char: another io_add_watch_poll fix · 0ca5aa4f
      由 Paolo Bonzini 提交于 
      After attaching the source, we have to remove the reference we hold
to it, because we do not hold anymore a pointer to the source.

If we do not do this, removing the source will not finalize it and
will not drop the "real" I/O watch source.

This showed up when backporting the new flow control patches to older
versions of QEMU that still used select.  The whole select then failed
with EBADF (poll instead will reporting POLLNVAL on a single pollfd)
and QEMU froze.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1365600207-21685-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      0ca5aa4f
  39. 08 4月, 2013 1 次提交
    • P
      qemu-char: really fix behavior on can_read = 0 · 1e885b25
      由 Paolo Bonzini 提交于 
      I misread the glib manual, g_source_remove does not let you re-attach
the source later.  This behavior (called "blocking" the source in glib)
is present in glib's source code, but private and not available outside
glib; hence, we have to resort to re-creating the source every time.

In fact, g_source_remove and g_source_destroy are the same thing,
except g_source_destroy is O(1) while g_source_remove scans a potentially
very long list of GSources in the current main loop.  Ugh.  Better
use g_source_destroy explicitly, and leave "tags" to those dummies who
cannot track their pointers' lifetimes.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1365426195-12596-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      1e885b25
  41. 06 4月, 2013 1 次提交
    • P
      qemu-char: eliminate busy waiting on can_read returning zero · d185c094
      由 Paolo Bonzini 提交于 
      The character backend refactoring introduced an undesirable busy wait.
The busy wait happens if can_read returns zero and there is data available
on the character device's file descriptor.  Then, the I/O watch will
fire continuously and, with TCG, the CPU thread will never run.

    1) Char backend asks front end if it can write
    2) Front end says no
    3) poll() finds the char backend's descriptor is available
    4) Goto (1)

What we really want is this (note that step 3 avoids the busy wait):

    1) Char backend asks front end if it can write
    2) Front end says no
    3) poll() goes on without char backend's descriptor
    4) Goto (1) until qemu_chr_accept_input() called

    5) Char backend asks front end if it can write
    6) Front end says yes
    7) poll() finds the char backend's descriptor is available
    8) Backend handler called

After this patch, the IOWatchPoll source and the watch source are
separated.  The IOWatchPoll is simply a hook that runs during the prepare
phase on each main loop iteration.  The hook adds/removes the actual
source depending on the return value from can_read.

A simple reproducer is

    qemu-system-i386 -serial mon:stdio

... followed by banging on the terminal as much as you can. :)  Without
this patch, emulation will hang.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1365177573-11817-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      d185c094
  43. 05 4月, 2013 3 次提交