On 22/03/2017 12:07, Peter Maydell wrote: > That's not the end that's a problem. Here we know we have > data available from the Windows end to read, we just > can't feed it to the QEMU UART model yet because the > UART model is saying "my FIFO is full, try later". > We should be able to handle that. (I couldn't figure > out how it works for the socket code either.)
On every iteration of the glib main loop, tcp_chr_read_poll returns zero and io_watch_poll_prepare removes any previously created QIOChannel event source for the file descriptor When hw/char/pl011.c has free space in the FIFO tcp_chr_read_poll returns nonzero, io_watch_poll_prepare adds again the QIOChannel event source, the event source calls tcp_chr_read which reads from the socket and passes the data to the PL011. qemu_chr_fe_accept_input is only needed to force another call to tcp_chr_read_poll. Paolo
