Re: [Qemu-devel] [BUG] GTK terminal is broken

[Laszlo Ersek]

On 07/29/13 20:18, Stefan Weil wrote:
> Am 29.07.2013 20:05, schrieb Anthony Liguori:
>> Stefan Weil <address@hidden> writes:
>>
>>> Hello,
>>>
>>> maybe most developers will already have noticed that the terminal output
>>> in QEMU's GTK user interface is broken. As far as I know, it never worked,
>>> but as there are working alternatives, I did not care much and forgot to
>>> report the issues.
>>>
>>> See these snapshots which show the problems with QEMU's GTK terminals:
>>>
>>> http://qemu.weilnetz.de/test/bugs/qemu-gtk-demo1.png
>>>
>>> Here the first line of the QEMUmonitor is only partially visible.
>>> Tested with Cygwin/X on W64 host, QEMU running on Debian Linux.
>>> Other X servers (e.g. native X on Debian Linux) don't show this
>>> problem.
>> It's a GTK/Cygwin/X bug.
>>
>> We use a vbox without anything particularly fancy happening.  Looks like
>> something is calculating layout incorrectly.
>>
>> Regards,
>>
>> Anthony Liguori
> 
> I miss a comment on the more important next two points.
> They are _not_ related to Cygwin / X.
> 
> Do you investigate them?

I did some investigation, and the results are not pretty. I'm using
RHEL-6.4 host OS (kernel, gtk, vte etc), with fresh upstream qemu. The
command line (started as a mere user --> TCG) was

./qemu-system-x86_64 -cdrom
/home/virt-images/isos/Fedora-18-x86_64-Live-XFCE.iso

Please find the attached debug patch (it has a small functional change
as well, I'll discuss it below).

(a) The patch extends the qemu_hexdump() function with ASCII strings. I
wanted to ask you to run your tests with this patch applied, and try to
correlate the hexdumps with the breakage on the screen.

However, when testing the patch myself, I ran into problems.

(b) The patch adds a qemu_set_nonblock(slave_fd) call to gd_vc_init(). I
tested the patch both with and without this hunk.

The key is to produce big output for VTE. For that purpose I waited
until the Fedora 18 kernel enabled paging, and then issued "info tlb".

("info tlb" should be familiar from a recent monitor bugfix, as test
case / trigger, but in bleeding edge qemu the monitor is OK.)

So, if I do not add (b), the debug patch starts to spew data to stderr,
and after a while qemu hangs hard, in the write() call in gd_vc_chr_write().

If I add (b), then the same happens initially, followed by qemu spinning
(ie. entering and exiting rapidly, without making any progress)
gd_vc_chr_write(), with write() returning -1/EAGAIN.

VTE seems to expect the owner of the slave side to run in a different
process or thread. While browsing vte_terminal_io_read(), I found some
throttling code in the read path, where VTE tries to keep one child
process (maybe running in one tab?) to monopolize it.

I think this could explain the deadlock / busy wait behavior. In qemu
both sides of the terminal are manipulated by the same thread, and both
file descriptors are (should be) added to the same GLib main loop. At
some point VTE would be able read the master side but refuses to, the
pty buffer becomes full, the slave-side write() in gd_vc_chr_write()
blocks, and VTE never gets back control to release the throttle.

This doesn't explain why qemu never recovers when the slave side is set
to non-blocking mode (ie. with (b) added). I suspect that although we
manage to run circles around the main loop in this case, we either never
reach the master-fd read in VTE, or VTE always decides it's still too
early to read.

Laszlo

0001-gd_vc_chr_write-print-hexdump-set-nonblock.patch
Description: Text document