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

[Andrey Korolyov]

On Thu, Sep 4, 2014 at 1:46 PM, Kirill Batuzov <address@hidden> wrote:
> On Wed, 3 Sep 2014, Andrey Korolyov wrote:
>
>> Given 2.1 and isa-serial output, set as ttyS0 for the guest VM with
>> 9600 baud rate.
>>
>> The test case is quite simple - display as much data as possible over
>> serial console and do not hang the system. While qemu-1.1 works
>> perfectly, with complaining for lost interrupts (known bug for used
>> guest kernel), 2.1 just hangs after some seconds, eating up all
>> available cpu quota.
>>
>> Test case is 'while true; dmesg; done' in serial console. I`d like to
>> ask to consider this bug as very serious as VM going completely
>> unresponsive in matter of tens of seconds and there are a lot of side
>> attacks to produce enough number of printk() to the ttyS0 with serial
>> console being set up and default settings for almost any distro in
>> such a way that message suppression would not work and VM can be DoSed
>> by an unprivileged user.
>>
>>
>
> I tried to reproduce the described behaviour with aboriginal linux and
> QEMU 2.1.0 but without luck.
>
> The configurations I tried:
>
> qemu-system-i386 -cpu pentium3 -no-reboot -kernel bzImage -hda hda.sqf \
>   -append "root=/dev/hda rw init=/sbin/init.sh panic=1 console=ttyS0 
> HOST=i686"
>
> qemu-system-i386 -cpu pentium3 -no-reboot -kernel bzImage -hda hda.sqf \
>   -append "root=/dev/hda rw init=/bin/ash panic=1 console=ttyS0,9600 
> HOST=i686"
>
> With all output the system did not hang. In particular I alway could
> switch to QEMU monitor and stop the VM from there.
>
> Can you give an exact QEMU command line which leads to the bug?
>
> --
> Kirill


Thanks, the launch string can be borrowed from attach here:
http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00482.html,
the same VM is going under test.


By hang I mean stopping ability to send icmp replies, it is like a
kind of a watermark for issues I count serious after. Just tested
again, the ceiling is not exactly representing all available cpu quota
*every* time but is rounded by seemingly random count of cores from 3.
to 9 in mine series of tests, with quota limit of 12. VM became
unresponsive in matter of seconds, consumption raising by 'clicking'
core count for about a half of minute, stabilizing then. Guest args
are console=tty0 console=ttyS0,9600n8.