Re: [PATCH] hw/char/pl011: Output characters using best-effort mode

[Gavin Shan]

On 2/21/20 11:44 PM, Peter Maydell wrote:
> On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini <address@hidden> 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