Original Qemu serial.c uses non-waiting write. If it''s bound to a physical serial port, there are chances that write need to wait for a while. In this occasion, the characters are lost. This patch adds an up to 100ms wait for write. In addition, it turns off output processing. Currently we can debug HVM Windows with windbg running on another machine. To do so, 1) Serial driver in xen0 must be enabled 2) Add serial=''/dev/ttySX" (ttySX is a physical device name registered by serial driver) in HVM configure file 3) Add xencons=ttySY (ttySY is a pseudo device name, say ttyS8, other than any serial device name) in grub. Otherwise, Xen virtual console will try to register ttyS1 by default which is grubbed by serial drivers and fail. 4) Add debug options (e.g. /debug /debugport=COM1 /baudrate=57600) in HVM Windows'' boot.ini. Thanks, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Original Qemu serial.c uses non-waiting write. If it''s bound to a > physical serial port, there are chances that write need to wait for a > while. In this occasion, the characters are lost. This patch adds anup> to 100ms wait for write. In addition, it turns off output processing.Xiaowei, Thanks for investigating this. A couple of questions: diff -r 041be3f6b38e tools/ioemu/hw/serial.c --- a/tools/ioemu/hw/serial.c Tue Sep 19 13:26:47 2006 +++ b/tools/ioemu/hw/serial.c Tue Sep 19 15:47:11 2006 @@ -160,7 +160,8 @@ s->lsr &= ~UART_LSR_THRE; serial_update_irq(s); ch = val; - qemu_chr_write(s->chr, &ch, 1); + if (qemu_chr_write(s->chr, &ch, 1) == -1) + fprintf(logfile, "serial write error\n"); s->thr_ipending = 1; s->lsr |= UART_LSR_THRE; s->lsr |= UART_LSR_TEMT; Doesn''t the above mean we still drop the character? Shouldn''t we be storing the character somewhere and retrying it later? We should probably also clear the tx ready bit (bit 5) in the UART''s Line Status Register. We should then retry the write in ~100ms, and set the tx ready bit again. diff -r 041be3f6b38e tools/ioemu/vl.c --- a/tools/ioemu/vl.c Tue Sep 19 13:26:47 2006 +++ b/tools/ioemu/vl.c Tue Sep 19 15:47:11 2006 @@ -1191,7 +1191,7 @@ FD_ZERO(&writefds); FD_SET(fd, &writefds); timeout.tv_sec = 0; - timeout.tv_usec = 0; + timeout.tv_usec = 100000; sel_ret = select(max_fd + 1, NULL, &writefds, 0, &timeout); if (sel_ret <= 0) { /* Timeout or select error */ @@ -1674,7 +1674,8 @@ tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP |INLCR|IGNCR|ICRNL|IXON); - tty.c_oflag |= OPOST; + tty.c_oflag &= ~OPOST; + tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG); tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS); switch(data_bits) { What does this part of the patch do? I don''t know my tcsetattrs very well. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>diff -r 041be3f6b38e tools/ioemu/hw/serial.c >--- a/tools/ioemu/hw/serial.c Tue Sep 19 13:26:47 2006 >+++ b/tools/ioemu/hw/serial.c Tue Sep 19 15:47:11 2006 >@@ -160,7 +160,8 @@ > s->lsr &= ~UART_LSR_THRE; > serial_update_irq(s); > ch = val; >- qemu_chr_write(s->chr, &ch, 1); >+ if (qemu_chr_write(s->chr, &ch, 1) == -1) >+ fprintf(logfile, "serial write error\n"); > s->thr_ipending = 1; > s->lsr |= UART_LSR_THRE; > s->lsr |= UART_LSR_TEMT; > >Doesn''t the above mean we still drop the character? Shouldn''t we be >storing the character somewhere and retrying it later? We should >probably also clear the tx ready bit (bit 5) in the UART''s Line Status >Register. We should then retry the write in ~100ms, and set the txready>bit again. >After timeout mechanism added, there isn''t any character lost. In fact, we don''t see any character lost with timeout=50ms. So 100ms should be a very safe value IMO. Print here is just for debug purpose, to indicate system abnormity.> >diff -r 041be3f6b38e tools/ioemu/vl.c >--- a/tools/ioemu/vl.c Tue Sep 19 13:26:47 2006 >+++ b/tools/ioemu/vl.c Tue Sep 19 15:47:11 2006 >@@ -1191,7 +1191,7 @@ > FD_ZERO(&writefds); > FD_SET(fd, &writefds); > timeout.tv_sec = 0; >- timeout.tv_usec = 0; >+ timeout.tv_usec = 100000; > sel_ret = select(max_fd + 1, NULL, &writefds, 0, &timeout); > if (sel_ret <= 0) { > /* Timeout or select error */ >@@ -1674,7 +1674,8 @@ > > tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP > |INLCR|IGNCR|ICRNL|IXON); >- tty.c_oflag |= OPOST; >+ tty.c_oflag &= ~OPOST; >+ > tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG); > tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS); > switch(data_bits) { > >What does this part of the patch do? I don''t know my tcsetattrs very >well. >~OPOST disables output processing (e.g.: map NL to CR-NL on output). With output and input processing both disabled, windbg host and target can receive the raw data of the other end separately, and interpret them in their own way. Thanks, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24/9/06 23:13, "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:> - qemu_chr_write(s->chr, &ch, 1); > + if (qemu_chr_write(s->chr, &ch, 1) == -1) > + fprintf(logfile, "serial write error\n"); > s->thr_ipending = 1; > s->lsr |= UART_LSR_THRE; > s->lsr |= UART_LSR_TEMT; > > Doesn''t the above mean we still drop the character? Shouldn''t we be > storing the character somewhere and retrying it later? We should > probably also clear the tx ready bit (bit 5) in the UART''s Line Status > Register. We should then retry the write in ~100ms, and set the tx ready > bit again.There''s not even any need to poll, if the serial fd is in the set of writefd''s. Buffering internally to some reasonable limit and then clearing THRE until the fd appears in the pollset and some FIFO space is cleared is the right thing to do. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel