Re: Qemu resets terminal to crazy defaults

[Fabiano Rosas]

BALATON Zoltan <balaton@eik.bme.hu> writes:

> On Wed, 20 Dec 2023, Fabiano Rosas wrote:
>> Warner Losh <imp@bsdimp.com> writes:
>>
>>> On Tue, Dec 19, 2023, 1:55 PM Peter Maydell <peter.maydell@linaro.org>
>>> wrote:
>>>
>>>> On Tue, 19 Dec 2023 at 19:40, Fabiano Rosas <farosas@suse.de> wrote:
>>>>>
>>>>> Dave Blanchard <dave@killthe.net> writes:
>>>>>
>>>>>> Hello all, can you please help me to understand what Qemu is doing
>>>> here?
>>>>>>
>>>>>> When connecting to the guest for example using a serial/tcp/telnet
>>>> link, some kind of code is being immediately transmitted over the link
>>>> which screws up my Xterm terminal settings, including changing the text
>>>> cursor shape and most notably, disabling wraparound of long lines, so that
>>>> they get truncated at the edge of the window instead.
>>>>>>
>>>>>> Can this behavior be disabled by command line, and if not, what is the
>>>> code doing exactly so I can know where to disable it? I tried disabling all
>>>> calls to tcsetattr() but that had no effect.
>>>>
>>>>> I looked into the automatic margins issue a long time ago and I seem to
>>>>> remember it was caused by the firmware (SeaBIOS) configuring the
>>>>> terminal and QEMU just never returning it to the original state. I
>>>>> eventually gave up trying to fix it because I was having trouble finding
>>>>> a reliable point in QEMU shutdown sequence to enable the capability
>>>>> back. Nowadays I just run 'tput smam' after quitting QEMU.
>>>>
>>>> To check whether this is happening because of the BIOS (or other
>>>> guest code) vs QEMU itself, you can try running QEMU in a configuration
>>>> where it doesn't run any BIOS code. One I happen to know offhand
>>>> is an arm one:
>>>>
>>>>    qemu-system-aarch64 -M virt -serial stdio
>>>>
>>>> This won't print anything, because we haven't loaded any guest
>>>> code at all and there's no default BIOS on this machine type.
>>>> (The emulated CPU is sat in effectively a tight loop taking
>>>> exceptions.) If that messes up the terminal settings, then it's
>>>> likely being done by something inside QEMU. If it doesn't, then
>>>> it sounds like as you say it'll be because of the SeaBIOS
>>>> firmware writing stuff to the terminal.
>>>>
>>>> (There might be a way to run the x86 PC machine without it
>>>> running a BIOS, for a similar test, but I don't know if there
>>>> is or how to do it off the top of my head.)
>>>>
>>
>> I tried using an empty bios file. I see with 'info registers' that the
>> vcpu is spinning. After quitting QEMU, the terminal state is unchanged:
>>
>> $ dd if=/dev/zero of=dummy-bios.bin count=256 bs=1k
>> $ qemu-system-x86_64 -nographic -bios ./dummy-bios.bin
>> $ <line wrap preserved>
>>
>> With SeaBIOS, the issue manifests:
>>
>> $ qemu-system-x86_64 -nographic
>> SeaBIOS (version rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org)
>> <bunch of boot and iPXE messages>
>> ...
>> $ <line wrap disabled>
>>
>>>> I do know that QEMU doesn't clean up things the guest does
>>>> to the terminal, because for instance if you have a serial
>>>> terminal and the guest puts it into "emit boldface/bright",
>>>> that doesn't go back to normal non-bold text when QEMU exits.
>>>> (It would be nice if it did do that...)
>>>>
>>>
>>> It would be nice indeed. Trouble is quarrying the state beforehand to know
>>> what to reset by random software producing effectively random bytes..
>>>
>>
>> Maybe we could focus on the more annoying/obvious state? The line wrap
>> issue is a very salient one, specially since QEMU command lines
>> themselves tend to take more than one line.
>>
>>> ESC c
>>>
>>> is the reset sequence as well...but that's likely too big a hammer.
>
> There's 'stty sane' which is supposed to reset to reasonable values, maybe 
> that could be used but I'm not sure it could fix all strange states. It's 
> better than reset as reset also drops scrollback history.
>
> Regards,
> BALATON Zoltan

For this one issue of linewrapping being disabled, we could probe the
state of the capability somewhere at QEMU start:

\033[?7$p
7;1$y  <-- 1 means enabled, 2 means disabled

And then restore it when shutting down. I think it would be worth it
because this issue has been present in QEMU for a long time. In fact,
this thread from 2019 from where I took the above information already
mentions QEMU "leaving the terminal in a weird state":

https://unix.stackexchange.com/questions/558770/how-to-query-the-terminal-state-that-is-set-by-escape-sequences-such-as-tput-sma

There's a catch though with the above escape sequence which is that
terminal multiplexers such as tmux and screen will not pass it down to
the terminal emulator as is. They both require some wrapping of the
sequence.

Screen requires: \033P<query sequence>\033\\
Tmux requires:   \033Ptmux;<query sequence>\033\\

with the sequence used by screen also working if given directly to the
terminal emulator (tested w/ TERM=xterm-256color via xfce-terminal), so
the only special case really is tmux.

I'd say we could have a routine, probably at char.c that probes the
state and registers an atexit handler (or similar) to restore the
state. In time, if we find more ways in which the guest can mess up the
terminal state, we could evaluate case-by-case and add code for the more
annoying issues.