On Fri, 21 Feb 2020 at 13:09, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 21/02/20 13:44, 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? > > Yes, it should be possible. But I must say I'm not sure why it exists > at all. Maybe it should be dropped instead. Instead, we should make > sure that after POLLHUP (the socket is disconnected) data is dropped.
The initial case reported by Gavin in this thread is "-serial tcp:127.0.0.1:50900" with the other end being a program which listens on TCP port 50900 and then sleeps without accepting any incoming connections, which blocks the serial port output and effectively blocks the guest bootup. If you want to insulate the guest from badly behaved consumers like that (or the related consumer who accepts the connection and then just doesn't read data from it) you probably need to deal with more than just POLLHUP. But I'm not sure how much we should care about these cases as opposed to just telling users not to do that... thanks -- PMM
