On 2/21/20 11:44 PM, Peter Maydell wrote:
On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini <pbonz...@redhat.com> wrote:
On 21/02/20 11:21, Peter Maydell wrote:
Before you do that, I would suggest investigating:
* is this a problem we've already had on x86 and that there is a
standard solution for
Disconnected sockets always lose data (see tcp_chr_write in
chardev/char-socket.c).
For connected sockets, 8250 does at most 4 retries (each retry is
triggered by POLLOUT|POLLHUP). After these four retries the output
chardev is considered broken, just like in Gavin's patch, and only a
reset will restart the output.
* should this be applicable to more than just the socket chardev?
What's special about the socket chardev?
For 8250 there's no difference between socket and everything else.
Interesting, I didn't know our 8250 emulation had this
retry-and-drop-data logic. Is it feasible to put it into
the chardev layer instead, so that every serial device
can get it without having to manually implement it?
It seems 8250 retries, but never drops data. s->tsr_retry is always
1 when neither G_IO_OUT nor G_IO_HUP happens. In that case, there is
always a asynchronous IO handler (serial_xmit()), which will be scheduled
on event G_IO_OUT, apart from G_IO_HUP. I don't think the event will be
triggered in our this particular case. This eventually has UART_LSR_THRE
cleared in LSR (0x5) to hold upper layer. So there is no data lost if I'm
correct.
It would be very rare running into successive 4 failures in 8250 because
serial_xmit() is called on G_IO_OUT event as G_IO_HUP is rare. I doubt the
logic has been ever used, maybe Marcandre Lureau knows the background.
Thanks,
Gavin
