qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Serial: possible hang during intensive interaction over


From: Kirill Batuzov
Subject: Re: [Qemu-devel] Serial: possible hang during intensive interaction over the console
Date: Tue, 9 Sep 2014 19:28:00 +0400 (MSK)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Fri, 5 Sep 2014, Andrey Korolyov wrote:

> >
> > Heh, it is kernel- (defaults-) dependent after all. Debian hangs
> > always, on 3.10, 3.14 and 3.16, Fedora 20 works fine on 3.15. I`ll
> > check if there are any 82550-specific patches in Fedora tree a bit
> > later.
> 
> 
> It is a setting-dependent issue, checked this. Though I am still
> searching which option causing such a huge difference, vast majority
> of distros with default kernels hanged completely during test. Stock
> SuSE/CentOS/Debian kernels can be used for testing.
>

I managed to reproduce it finally with debian live image. Resulting
command line was:

qemu-system-x86_64 -enable-kvm -m 512 -smp 12  \
          -cdrom debian-live-7.6.0-amd64-standard.iso

Commands to run in guest console:
# yes > /dev/ttyS0 &
# yes > /dev/ttyS0 &

Looks like it is the old "serial8250: too much work for irq4" bug.

In short: QEMU serial port transmits data as fast as it can ignoring
baud rate completely. As a result we are stuck in serial8250_interrupt
ISR in kernel most of the time.

Overall we have a large issue with rate control and flow control for
virtual serial port implementations. In QEMU we have over dozen different
UARTs for different platforms. Among them only one uses baud rate
(strongarm) and only one implements flow control (16550A).

CC'ing some people to discuss general course of action in regards to
serial implementation.

We probably want some abstract "serial" which is able to transmit one
character with fixed baud rate and maximum retry count. The actual
serial port implementations should implement interrupts, control
registers and FIFO around it. With such design we will not need to
implement the same bits of rate control and retry logic for every UART
in QEMU.

Any thoughts on this?

-- 
Kirill



reply via email to

[Prev in Thread] Current Thread [Next in Thread]