On 22/11/23 11:38, Daniel P. Berrangé wrote:
On Wed, Nov 22, 2023 at 02:31:29PM +0400, Marc-André Lureau wrote:
Hi
On Thu, Nov 9, 2023 at 11:30 PM Philippe Mathieu-Daudé
<phi...@linaro.org> wrote:
If the UART back-end chardev doesn't drain data as fast as stdout
does or blocks, buffer in the TX FIFO to try again later.
This avoids having the IO-thread busy waiting on chardev back-ends,
reported recently when testing the Trusted Reference Stack and
using the socket backend:
https://linaro.atlassian.net/browse/TRS-149?focusedCommentId=149574
Implement registering a front-end 'watch' callback on back-end
events, so we can resume transmitting when the back-end is writable
again, not blocking the main loop.
I do not have access to that Jira issue.
In general, chardev backends should have some buffering already
(socket, files etc).
If we want more, or extra control over buffering, maybe this should be
implemented at the chardev level, rather than each frontend implement
its own extra buffering logic...
Regardless, I think frontends should have an option to "drop" data
when the chardev/buffer is full, rather than hanging.
Does anyone really want data to be dropped by QEMU ? Every time I've seen
a scenario where data has been dropped or lost, it has been considered
a bug to be solved.
A kind of counter example is the RX UART model, which is used in
embedded world and respects the baudrate timing. I guess some scripts
were working with the QEMU UART chardev, but them the same script
failed when using HW UART, so realistic HW baudrate was emulated using
the timer API. See the chardev frontend handlers:
static int can_receive(void *opaque)
{
RSCIState *sci = RSCI(opaque);
if (sci->rx_next > qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)) {
return 0;
} else {
return FIELD_EX8(sci->scr, SCR, RE);
}
}
The TX path also use a timer:
static void send_byte(RSCIState *sci)
{
if (qemu_chr_fe_backend_connected(&sci->chr)) {
qemu_chr_fe_write_all(&sci->chr, &sci->tdr, 1);
}
timer_mod(&sci->timer,
qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + sci->trtime);
The more complex 16550A UART model also use timer in FIFO mode.
Sure, we don't want QEMU to block on chardev writes, but we want that
more than throwing away data.
What's the use case for capturing data from the serial port, but throwing
it away if the other end of a socket doesn't read quickly enough ?
If someone does want lossy serial ports, they could configure the UDP
charedev backend already.
With regards,
Daniel
