On 22 March 2017 at 08:40, Paolo Bonzini <pbonz...@redhat.com> wrote: > >> > I am using a windows named pipe to get the data from a window >> > host program, which uses ReadFile () in char_win.c >> >> OK, bugs in the windows-specific char backend would be >> unsurprising. >> >> I'm not entirely sure how the chardev layer works, but >> at the pl011 end if we return 0 from our can_receive >> function then the chardev layer should decide it has >> nothing to do until the pl011 later calls >> qemu_chr_fe_accept_input(), I think. >> >> I've cc'd Paolo and Marc-André Lureau as the chardev >> maintainers. > > Windows named pipes do not support the equivalent of "select", > so it's possible that they cause a busy wait.
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.) thanks -- PMM
