Using error_is_set(errp) to check whether a function call failed is
fragile: it breaks when errp is null. Check perfectly suitable return
values instead when possible. As far as I can tell, errp can't be
null there, but this is more robust and more obviously correct
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fix a bug that was introduced in commit 386a5a1e. A removal of a device
set the chr handlers to NULL. However when the device is plugged back,
its read callback is not restored so data can't be transferred from the
host to the guest (e.g. via the virtio-serial port).
https://bugzilla.redhat.com/show_bug.cgi?id=1027181
Signed-off-by: Gal Hammer <ghammer@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce 'query-chardev-backends' QMP command which lists all
supported character device backends.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
error_is_set(&var) is the same as var != NULL, but it takes
whole-program analysis to figure that out. Unnecessarily hard for
optimizers, static checkers, and human readers. Dumb it down to
obvious.
Gets rid of several dozen Coverity false positives.
Note that the obvious form is already used in many places.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
This improves readability and simplifies the code.
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Teach the chardev frontend to send event. This is used by the Spice port
chardev currently.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
# By Amit Shah
# Via Amit Shah
* amit/char-remove-watch-on-unplug:
char: remove watch callback on chardev detach from frontend
char: use common function to disable callbacks on chardev close
char: move backends' io watch tag to CharDriverState
Message-id: 20131004154802.GA25646@grmbl.mre
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
# By Stefan Weil (5) and others
# Via Michael Tokarev
* mjt/trivial-patches:
migration: Fix compiler warning ('caps' may be used uninitialized)
util/path: Fix type which is longer than 8 bit for MinGW
hw/9pfs: Fix errno value for xattr functions
vl: Clean up unnecessary boot_order complications
qemu-char: Fix potential out of bounds access to local arrays
pci-ohci: Add missing 'break' in ohci_service_td
sh4: Fix serial line access for Linux kernels later than 3.2
hw/alpha: Fix compiler warning (integer constant is too large)
target-i386: Fix compiler warning (integer constant is too large)
block: Remove unused assignment (fixes warning from clang)
exec: cleanup DEBUG_SUBPAGE
tests: Fix schema parser test for in-tree build
tests: Update .gitignore for test-int128 and test-bitops
.gitignore: ignore tests/qemu-iotests/socket_scm_helper
Message-id: 1381051979-25742-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
Latest gcc-4.8 supports a new option -fsanitize=address which activates
an AddressSanitizer. This AddressSanitizer stops the QEMU system emulation
very early because two character arrays of size 8 are potentially written
with 9 bytes.
Commit 6ea314d914 added the code.
There is no obvious reason why width or height could need 8 characters,
so reduce it to 7 characters which together with the terminating '\0'
fit into the arrays.
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Alex Bennée <alex@bennee.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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.
https://bugzilla.redhat.com/show_bug.cgi?id=994414
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If a frontend device releases the chardev (via unplug), the chr handlers
are set to NULL via qdev's exit callbacks invoking
qemu_chr_add_handlers(). If the chardev had a pending operation, a
callback will be invoked, which will try to access data in the
just-released frontend, causing a segfault.
Ensure the callbacks are disabled when frontends release chardevs.
This was seen when a virtio-serial port was unplugged when heavy
guest->host IO was in progress (causing a callback to be registered).
In the window in which the throttling was active, unplugging ports
caused a qemu segfault.
https://bugzilla.redhat.com/show_bug.cgi?id=985205
CC: <qemu-stable@nongnu.org>
Reported-by: Sibiao Luo <sluo@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
This deduplicates code used a lot of times.
CC: <qemu-stable@nongnu.org>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
All the backends implement an io watcher tag for callbacks. Move it to
CharDriverState from each backend's struct to make accessing the tag from
backend-neutral functions easier.
This will be used later to cancel a callback on chardev detach from a
frontend.
CC: <qemu-stable@nongnu.org>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
# By Alex Bligh (32) and others
# Via Stefan Hajnoczi
* stefanha/block: (42 commits)
win32-aio: drop win32_aio_flush_cb()
aio-win32: replace incorrect AioHandler->opaque usage with ->e
aio / timers: remove dummy_io_handler_flush from tests/test-aio.c
aio / timers: Remove legacy interface
aio / timers: Switch entire codebase to the new timer API
aio / timers: Add scripts/switch-timer-api
aio / timers: Add test harness for AioContext timers
aio / timers: convert block_job_sleep_ns and co_sleep_ns to new API
aio / timers: Convert rtc_clock to be a QEMUClockType
aio / timers: Remove main_loop_timerlist
aio / timers: Rearrange timer.h & make legacy functions call non-legacy
aio / timers: Add qemu_clock_get_ms and qemu_clock_get_ms
aio / timers: Remove legacy qemu_clock_deadline & qemu_timerlist_deadline
aio / timers: Remove alarm timers
aio / timers: Add documentation and new format calls
aio / timers: Use all timerlists in icount warp calculations
aio / timers: Introduce new API timer_new and friends
aio / timers: On timer modification, qemu_notify or aio_notify
aio / timers: Convert mainloop to use timeout
aio / timers: Convert aio_poll to use AioContext timers' deadline
...
Message-id: 1377202298-22896-1-git-send-email-stefanha@redhat.com
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
This is an autogenerated patch using scripts/switch-timer-api.
Switch the entire code base to using the new timer API.
Note this patch may introduce some line length issues.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Convert stderr messages calling error_get_pretty()
to error_report().
Timestamp is prepended by -msg timstamp option with it.
Per Markus's comment below, A conversion from fprintf() to
error_report() is always an improvement, regardless of
error_get_pretty().
http://marc.info/?l=qemu-devel&m=137513283408601&w=2
But, it is not reasonable to convert them at one time
because fprintf() is used everwhere in qemu.
So, it should be done step by step with avoiding regression.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Since commit bd5c51e (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: James Hogan <james.hogan@imgtec.com>
Tested-by: Michael 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: Anthony Liguori <aliguori@us.ibm.com>
As of bd5c51ee6c, 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: Michael 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: Anthony Liguori <aliguori@us.ibm.com>
Commit 1da48c6 called the new member "memory" after commit 3949e59
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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 3949e59. Fix code to match documentation.
Keep the undocumented name working as an alias for compatibility.
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-3-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This reverts commit 6a85e60cb9.
Commit 51767e7 "qemu-char: Add new char backend CirMemCharDriver"
introduced a memory ring buffer character device driver named
"memory". Commit 3949e59 "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 6a85e60 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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-2-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The g_io_channel_write_chars() documentation states,
bytes_written: The number of bytes written. This can be nonzero even if
the return value is not G_IO_STATUS_NORMAL. [...]
io_channel_send() could lose such bytes before.
Furthermore, the (status == G_IO_STATUS_EOF) condition used to evaluate to
constant false whenever it was reached. When that condition actually held,
it always led to -1 / EINVAL. This patch (almost) distinguishes
G_IO_STATUS_EOF only when no bytes have been written, and then treats it
as an error.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1373998781-29561-2-git-send-email-lersek@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Any attempt to use it trips an "opt->desc->type == QEMU_OPT_NUMBER"
assertion. Broken in commit 1da48c65.
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
With mon:stdio you can exit the VM by switching to the monitor and
sending the "quit" command. It is then useful to pass Ctrl-C to the
VM instead of exiting.
This in turn lets us stop tying the default signal handling behavior
to -nographic, removing gratuitous differences between "-display none"
and "-nographic".
This patch changes behavior for "-display none -serial mon:stdio", as
expected, but not for "-display none -serial stdio".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1372868986-25988-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
# By Gerd Hoffmann (13) and Michael Tokarev (1)
# Via Michael Tokarev
* mjt/trivial-patches:
doc: we use seabios, not bochs bios
qemu-socket: don't leak opts on error
qemu-char: report udp backend errors
qemu-char: add -chardev mux support
qemu-char: minor mux chardev fixes
qemu-char: use ChardevBackendKind in CharDriver
qemu-char: don't leak opts on error
qemu-char: fix documentation for telnet+wait socket flags
qemu-char: print notification to stderr
qemu-char: use more specific error_setg_* variants
qemu-char: check optional fields using has_*
qemu-socket: catch monitor_get_fd failures
qemu-socket: drop pointless allocation
qemu-socket: zero-initialize SocketAddress
Message-id: 1372443465-22384-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Commit 2c5f488 introduced qapi-based character device initialization
as a new code path in qemu_chr_new_from_opts(). Unfortunately, it
failed to store parameter opts in the new chardev. Therefore,
qemu_chr_delete() doesn't delete it. Even though the device is gone,
its options linger, and any attempt to create another one with the
same ID fails.
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1372339512-28149-1-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Allow to explicitly create mux chardevs on the command line,
like you can using QMP.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
mux failure path has a memory leak. creating a mux chardev can't
fail though, so just assert() that instead of fixing an error path
which never ever runs anyway ...
Also fix bid being leaked while being at it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Local variables is_* should be bool by usage.
While at it, simplify the logic/code a bit.
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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: Michael Tokarev <mjt@tls.msk.ru>
Tested-by: Andreas Färber <andreas.faerber@web.de>
This removes <syslog.h> since we don't use
syslogging, and removes second, solaris-specific,
include of <net/if.h> (which is included in
a common part of the file)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
and it was issued as a bottom-half:
86e94dea5b
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 9f939df955, 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: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Michael 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: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fill unset CharDriverState->filename with the backend name, so
'info chardev' will return at least the chardev type. Don't
touch it in case the chardev init function filled it already,
like the socket+pty chardevs do for example.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch sets the filename when the new qapi backend
init from opts.
The previous patch and discussions as link below:
http://patchwork.ozlabs.org/patch/243896/
If anyone who have better idea to fix this please let
me know your suggestions.
Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com>
Message-id: 1369132079-11377-3-git-send-email-lilei@linux.vnet.ibm.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now we have memory char device, but the backend name of it
is a little confusion. We actually register it by 'memory', but
the description in qemu-option, the name of open functions
and the new api backend called it 'ringbuf'. It should keep
consistent. This patch named it all to 'memory'.
Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1369132079-11377-2-git-send-email-lilei@linux.vnet.ibm.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This unbreaks cross compile builds:
configure --target-list="i386-softmmu" --cpu=i386
When building on a 64bit machine.
Reported-by: David Holsgrove <david.holsgrove@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Message-id: 926326e96fd8685d74e9d5bf430fe4ad97a55289.1369191585.git.peter.crosthwaite@xilinx.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When register and open a chardev udp, the backend name should be udp
not dgram, and we do not have backend dgram in the chardev list. This
patch makes the new qapi udp backend consistent with the original
udp device.
Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com>
Message-id: 1369032665-18159-2-git-send-email-lilei@linux.vnet.ibm.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should fix building the GTK+ front-end on BSDs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1368533121-30796-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Hans de Goede <hdegoede@redhat.com>
Message-id: 1366890782-10311-1-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Message-id: 1366385529-10329-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Even if a CharDriverState's source is blocked by the front-end,
it must not be dropped. The IOWatchPoll that wraps it will take
care of adding and removing it to the main loop. Only remove
the source when the channel is closed; and in that case, make sure
that the wrapping IOWatchPoll is removed too.
These should just be theoretical bugs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1366385529-10329-4-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There is no need to use a timer and pty_chr_read to detect a connected
pty. It is simpler to just call g_poll periodically and check for POLLHUP.
It is done once per second, and only if the pty is disconnected, so it
is cheap enough.
Tested with "-monitor pty" and "-serial mon:pty", both of which work
correctly and do not freeze QEMU. (How to test ptys? "socat -,raw,echo=0
/dev/pts/4,raw").
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1366385529-10329-3-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Always check that the source is active, and zero the tag afterwards.
The occurrence in pty_chr_state will trigger with the next patch, the
others are just theoretical.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1366385529-10329-2-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* bonzini/hw-dirs:
exec: remove useless declarations from memory-internal.h
memory: move core typedefs to qemu/typedefs.h
include: avoid useless includes of exec/ headers
sysemu: avoid proliferation of include/ subdirectories
tpm: reorganize headers and split hardware part
configure: fix TPM logic
acpi.h: make it self contained
acpi: move declarations from pc.h to acpi.h
hw: Add lost ARM core again
Fix failure to create q35 machine
Add linux-headers to QEMU_INCLUDES
arm: fix location of some include files
Conflicts:
configure
aliguori: trivial conflict in configure output
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1365600207-21685-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1365426195-12596-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1365177573-11817-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It's not used anymore since the last commit.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
chardev-frontends need to explictly check, increase and decrement the
avail_connections "property" of the chardev when they are not using a
qdev-chardev-property for the chardev.
This fixes things like:
qemu-kvm -chardev stdio,id=foo -device isa-serial,chardev=foo \
-mon chardev=foo
Working, where they should fail. Most of the changes here are due to
old hardware emulation code which is using serial_hds directly rather then
a qdev-chardev-property.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364412581-3672-3-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add qemu_chr_fe_claim / _release helper functions for properly dealing with
avail_connections.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364412581-3672-2-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When we receive a file descriptor over a UNIX domain socket the
O_NONBLOCK flag is preserved. Clear the O_NONBLOCK flag and rely on
QEMU file descriptor users like migration, SPICE, VNC, block layer, and
others to set non-blocking only when necessary.
This change ensures we don't accidentally expose O_NONBLOCK in the QMP
API. QMP clients should not need to get the non-blocking state
"correct".
A recent real-world example was when libvirt passed a non-blocking TCP
socket for migration where we expected a blocking socket. The source
QEMU produced a corrupted migration stream since its code did not cope
with non-blocking sockets.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
The fcntl(fd, F_SETFL, O_NONBLOCK) flag is not specific to sockets.
Rename to qemu_set_nonblock() just like qemu_set_cloexec().
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
The current code is oddly written and have equally odd semantics.
Despite the '_all' suffix, upon EAGAIN the result will be a partial
write but instead of returning the partial write, we return EAGAIN.
Change the behavior to write as much as we can until we get an EAGAIN
returning a partial write if we do.
Reported-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1364575190-731-1-git-send-email-aliguori@us.ibm.com
Resending the be_open event only is useful when a frontend is registering, not
when it is unregistering.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-9-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The decrement of avail_connections is done in qdev-properties-system move
the increment there too for proper balancing of the calls.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-8-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Most frontends can't really determine if the guest actually has the frontend
side open. So lets automatically generate fe_open / fe_close as soon as a
frontend becomes ready (as signalled by calling qemu_chr_add_handlers) /
becomes non ready (as signalled by setting all handlers to NULL).
And allow frontends which can actually determine if the guest is listening to
opt-out of this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-5-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add tracking of the fe_open state to struct CharDriverState.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-4-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To better reflect that it is for handling a backend being opened.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-3-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Rename the opened variable to be_open to reflect that it contains the
opened state of the backend.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-2-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu_chr_fe_add_watch() can return negative errors, therefore it must
not have an unsigned return type. For consistency with other
qemu_chr_fe_* functions, this uses a standard C int instead of glib
types.
In situations where qemu_chr_fe_add_watch() is falsely assumed to have
succeeded, the serial ports would go into a state where it never becomes
ready for transmitting more data; this is fixed by this patch.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Current colon position in "waiting for telnet connection" message template
produces messages like:
QEMU waiting for connection on: telnet::127.0.0.16666,server
After moving a colon to the right, we will get a correct messages like:
QEMU waiting for connection on: telnet:127.0.0.1:6666,server
Signed-off-by: Igor Mitsyanko <i.mitsyanko@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'memory' support to qapi and also switches over
the memory chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'vc' support to qapi and also switches over the
vc chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'pipe' support to qapi and also switches over the
pipe chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'console' support to qapi and also switches over the
console chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch switches over the pty chardev initialization
to the new qapi code path.
Bonus: Taking QemuOpts out of the loop allows some nice
cleanups along the way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'stdio' support to qapi and also switches over the
stdio chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'braille' support to qapi and also switches over
the braille chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds 'msmouse' support to qapi and also switches over
the msmouse chardev initialization to the new qapi code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch add support for a new way to initialize chardev devices.
Instead of calling a initialization function with a QemuOpts we will
now create a (qapi) ChardevBackend, optionally call a function to
fill ChardevBackend from QemuOpts, then go create the chardev using
the new qapi code path which is also used by chardev-add.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch is based of off version 9 of Stefan Berger's patch series
"QEMU Trusted Platform Module (TPM) integration"
and adds a new backend driver for it.
This patch adds a passthrough backend driver for passing commands sent to the
emulated TPM device directly to a TPM device opened on the host machine.
Thus it is possible to use a hardware TPM device in a system running on QEMU,
providing the ability to access a TPM in a special state (e.g. after a Trusted
Boot).
This functionality is being used in the acTvSM Trusted Virtualization Platform
which is available on [1].
Usage example:
qemu-system-x86_64 -tpmdev passthrough,id=tpm0,path=/dev/tpm0 \
-device tpm-tis,tpmdev=tpm0 \
-cdrom test.iso -boot d
Some notes about the host TPM:
The TPM needs to be enabled and activated. If that's not the case one
has to go through the BIOS/UEFI and enable and activate that TPM for TPM
commands to work as expected.
It may be necessary to boot the kernel using tpm_tis.force=1 in the boot
command line or 'modprobe tpm_tis force=1' in case of using it as a module.
Regards,
Andreas Niederl, Stefan Berger
[1] http://trustedjava.sourceforge.net/
Signed-off-by: Andreas Niederl <andreas.niederl@iaik.tugraz.at>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
Reviewed-by: Joel Schopp <jschopp@linux.vnet.ibm.com>
Message-id: 1361987275-26289-6-git-send-email-stefanb@linux.vnet.ibm.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Markus Armbruster