No need to keep explicit_fe_open around if it affects only a
qemu_chr_fe_set_handlers(). Use an additional argument instead.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-24-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In most cases, front ends do not care about the side effect of
CharBackend, so we can simply skip the checks and call the qemu_chr_fe
functions even without associated CharDriver.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-20-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This also switches from qemu_chr_add_handlers() to
qemu_chr_fe_set_handlers(). Note that qemu_chr_fe_set_handlers() now
takes the focus when fe_open (qemu_chr_add_handlers() did take the
focus)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-16-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
qemu_chr_accept_input() and qemu_chr_disconnect() are only used by
frontend, so use qemu_chr_fe prefix.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-14-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Store the property in a CharBackend instead of CharDriverState*. This
also replace systematically chr by chr.chr to access the
CharDriverState*. The following patches will replace it with calls to
qemu_chr_fe CharBackend functions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-12-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The qemu_chr_fe_write method will return -1 on EAGAIN if the
chardev backend write would block. Almost no callers of the
qemu_chr_fe_write() method check the return value, instead
blindly assuming data was successfully sent. In most cases
this will lead to silent data loss on interactive consoles,
but in some cases (eg RNG EGD) it'll just cause corruption
of the protocol being spoken.
We unfortunately can't fix the virtio-console code, due to
a bug in the Linux guest drivers, which would cause the
entire Linux kernel to hang if we delay processing of the
incoming data in any way. Fixing this requires first fixing
the guest driver to not hold spinlocks while writing to the
hvc device backend.
Fixes bug: https://bugs.launchpad.net/qemu/+bug/1586756
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1473170165-540-4-git-send-email-berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* drop qemu_char_get_next_serial and use chardev prop
* add pl011_create wrapper function to create pl011 uart device
* change affected board code to use the new way
Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com>
Message-id: 1465028065-5855-2-git-send-email-zxq_yx_007@163.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1453832250-766-13-git-send-email-peter.maydell@linaro.org
Device models aren't supposed to go on fishing expeditions for
backends. They should expose suitable properties for the user to set.
For onboard devices, board code sets them.
A number of sysbus devices pick up block backends in their init() /
instance_init() methods with drive_get_next() instead: sl-nand,
milkymist-memcard, pl181, generic-sdhci.
Likewise, a number of sysbus devices pick up character backends in
their init() / realize() methods with qemu_char_get_next_serial():
cadence_uart, digic-uart, etraxfs,serial, lm32-juart, lm32-uart,
milkymist-uart, pl011, stm32f2xx-usart, xlnx.xps-uartlite.
All these mistakes are already marked FIXME. See the commit that
added these FIXMEs for a more detailed explanation of what's wrong.
Fortunately, only machines ppce500 and pseries-* support -device with
sysbus devices, and none of the devices above is supported with these
machines.
Set cannot_instantiate_with_device_add_yet to preserve our luck.
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Antony Pavlov <antonynpavlov@gmail.com>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Character devices defined with -serial and -parallel are for board
initialization to wire up. Board code examines serial_hds[] and
parallel_hds[] to find them, and creates devices with their qdev
chardev properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a chardev property for board code to set: they use
serial_hds[] (often via qemu_char_get_next_serial()) or parallel_hds[]
in their realize() or init() method to connect to a backend.
Picking up backends that way works when the devices are created by
board code. But it's inappropriate for -device or device_add. Not
only is it inconsistent with how the other characrer device models
work (they connect to a backend explicitly identified by a "chardev"
property), it breaks when the backend has been picked up by the board
or a previous -device / device_add already.
Example:
$ qemu-system-ppc64 -M bamboo -S -device i82378 -device pc87312 -device pc87312
qemu-system-ppc64: -device pc87312: Property 'isa-parallel.chardev' can't take value 'parallel0', it's in use
Mark them with suitable FIXME comments.
Cc: Li Guang <lig.fnst@cn.fujitsu.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Antony Pavlov <antonynpavlov@gmail.com>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <andreas.faerber@web.de>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
After commit 767adce2d, they are redundant. This way we don't assign them
except when needed. Once there, there were lots of cases where the ".fields"
indentation was wrong:
.fields = (VMStateField []) {
and
.fields = (VMStateField []) {
Change all the combinations to:
.fields = (VMStateField[]){
The biggest problem (apart from aesthetics) was that checkpatch complained
when we copy&pasted the code from one place to another.
Signed-off-by: Juan Quintela <quintela@redhat.com>
[PMM: fixed minor conflict, corrected commit message typos]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The receive fifo full bit should be set when 1 character is received and
the fifo is disabled or when 16 characters are in the fifo.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-4-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Offset 4 is UARTRSR/UARTECR, not the UARTCR. The UARTCR would be
corrupted if the UARTRSR is ever written. Fix by implementing a correct
model of the UARTRSR/UARTECR register. Reads of this register simply
reflect the error bits in data register. Only breaks can be triggered in
QEMU. With the pl011_can_receive function, we effectively have flow
control between the host and the model. Framing and parity errors simply
don't make sense in the model and will never occur.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-3-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Intermittent issues have been seen where no serial input occurs. It
appears the pl011 gets in a state where the rx interrupt never fires
because the rx interrupt only asserts when crossing the fifo trigger
level. The fifo state appears to get out of sync when the pl011 is
re-configured. This combined with the rx timeout interrupt not being
modeled results in no more rx interrupts.
Disabling the fifo is the recommended way to clear the tx fifo in the
TRM (section 3.3.8). The behavior in this case for the rx fifo is
undefined in the TRM, but having fifo contents to be maintained during
configuration changes is not likely expected behavior. Reseting the
fifo state when the fifo size is changed is the simplest solution.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-2-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Let the Luminary variant inherit from the ARM one, overwriting its ID on
instance_init. Introduce type constant and use QOM casts. Replace
triplicated SysBusDevice initfn with QOM realizefn and instance_init.
Signed-off-by: Andreas Färber <afaerber@suse.de>
