Hi, now it is working with the following char-pipe_new.c. See the patch. Doing the "if fifo has space" polling only when there are data on the pipe, and next reading from pipe. The sub_thread does these three things, and the main thread only does writing to UART fifo when the subthread signalled its handler.
It is working in my case to transfer large data. Rational? Please check. On 24 March 2017 at 08:24, Jiahuan Zhang <jiahuanzhan...@gmail.com> wrote: > Hi, here are the patch files for char-pipe.c, char-win.c, char-win.h > > > On 23 March 2017 at 18:31, Paolo Bonzini <pbonz...@redhat.com> wrote: > >> >> >> On 23/03/2017 18:28, Jiahuan Zhang wrote: >> > Hi, the method doesn't work for pipe. It still causes the same issue. >> > The only difference is that the first byte in the UART fifo can be read >> > by the guest app. >> > So now my guest app can immediately read 17bytes when the host is >> > sending data continuously, >> > then guest app is unable to read. >> > >> > Now there is a solution-to-be. Set the qemu pipe chardev to wait for 1 >> > millisecond before do a next ReadFile(), >> > then the pl011 can deliver the complete large data by the 16-byte fifo >> > continuously to the guest app. >> > >> > Is it rational? Or is this host -CPU-dependent? >> >> Post the patch, maybe you have a bug. >> >> Paolo >> > >
char-pipe_new.patch
Description: Binary data
