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

2020-02-23 Thread Gavin Shan
Hi Marc, On 2/21/20 8:09 PM, Marc Zyngier wrote: On 2020-02-21 04:24, Gavin Shan wrote: On 2/20/20 9:10 PM, Peter Maydell wrote: On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote: On 2020-02-20 06:01, Gavin Shan wrote: This fixes the issue by using newly added API qemu_chr_fe_try_write_all()

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

2020-02-23 Thread Gavin Shan
On 2/22/20 5:15 AM, Paolo Bonzini wrote: On 21/02/20 14:14, Peter Maydell wrote: 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

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

2020-02-23 Thread Gavin Shan
On 2/21/20 11:44 PM, Peter Maydell wrote: On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini 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 so

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

2020-02-21 Thread Paolo Bonzini
On 21/02/20 14:14, Peter Maydell wrote: > 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 e

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

2020-02-21 Thread Peter Maydell
On Fri, 21 Feb 2020 at 13:09, Paolo Bonzini wrote: > > On 21/02/20 13:44, Peter Maydell wrote: > > On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini 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

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

2020-02-21 Thread Paolo Bonzini
On 21/02/20 13:44, Peter Maydell wrote: > On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini 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 >> Di

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

2020-02-21 Thread Peter Maydell
On Fri, 21 Feb 2020 at 11:44, Paolo Bonzini 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_

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

2020-02-21 Thread Paolo Bonzini
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, 825

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

2020-02-21 Thread Peter Maydell
On Fri, 21 Feb 2020 at 04:24, Gavin Shan wrote: > If above analysis is correct and the first approach doesn't work out. We have > to > consider the 2nd approach - adding option to backend to allow losing data. I'm > going to add "allow-data-lost" option for TYPE_CHARDEV_SOCKET. With the > option

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

2020-02-21 Thread Marc Zyngier
Hi Gavin, On 2020-02-21 04:24, Gavin Shan wrote: Hi Peter and Marc, On 2/20/20 9:10 PM, Peter Maydell wrote: On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote: On 2020-02-20 06:01, Gavin Shan wrote: This fixes the issue by using newly added API qemu_chr_fe_try_write_all(), which provides ano

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

2020-02-20 Thread Gavin Shan
Hi Peter and Marc, On 2/20/20 9:10 PM, Peter Maydell wrote: On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote: On 2020-02-20 06:01, Gavin Shan wrote: This fixes the issue by using newly added API qemu_chr_fe_try_write_all(), which provides another type of service (best-effort). It's different

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

2020-02-20 Thread Peter Maydell
On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote: > > On 2020-02-20 06:01, Gavin Shan wrote: > > This fixes the issue by using newly added API > > qemu_chr_fe_try_write_all(), > > which provides another type of service (best-effort). It's different > > from > > qemu_chr_fe_write_all() as the data

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

2020-02-20 Thread Marc Zyngier
On 2020-02-20 06:01, Gavin Shan wrote: Currently, PL011 is used by ARM virt board by default. It's possible to block the system from booting. With below parameters in command line, the backend could run into endless attempts of transmitting packets, which can't succeed because of running out of

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

2020-02-20 Thread Gavin Shan
Hi Philippe, On 2/20/20 7:47 PM, Philippe Mathieu-Daudé wrote: Cc'ing the chardev maintainers: ./scripts/get_maintainer.pl -f chardev/char-fe.c "Marc-André Lureau" (maintainer:Character device...) Paolo Bonzini (reviewer:Character device...) qemu-devel@nongnu.org (open list:All patches CC he

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

2020-02-20 Thread Philippe Mathieu-Daudé
Hi Gavin, Cc'ing the chardev maintainers: ./scripts/get_maintainer.pl -f chardev/char-fe.c "Marc-André Lureau" (maintainer:Character device...) Paolo Bonzini (reviewer:Character device...) qemu-devel@nongnu.org (open list:All patches CC here) On 2/20/20 7:01 AM, Gavin Shan wrote: Currentl

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

2020-02-19 Thread Gavin Shan
Currently, PL011 is used by ARM virt board by default. It's possible to block the system from booting. With below parameters in command line, the backend could run into endless attempts of transmitting packets, which can't succeed because of running out of sending buffer. The socket might be not ac