Qemu resets terminal to crazy defaults

Qemu resets terminal to crazy defaults

[Dave Blanchard]

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.

Dave

Re: Qemu resets terminal to crazy defaults

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Tue, Dec 19, 2023, 12:20 PM Dave Blanchard <dave@killthe.net> wrote:

> 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.
>

Is it qemu doing this or your boit loader. What you describe has nothing to
do with tcsetattr, and everything to do with the state of your terminal
emulation... which is controlled with escape sequences...

Warner


Dave
>
>

[-- Attachment #2: Type: text/html, Size: 1526 bytes --]

Re: Qemu resets terminal to crazy defaults

[Fabiano Rosas]

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.
>
> Dave

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.

Not a lot of help, I know. Hopefuly someone else has more information
about this. I'd be interested in finding a proper solution for this
situation.

Re: Qemu resets terminal to crazy defaults

[Peter Maydell]

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 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...)

thanks
-- PMM

Re: Qemu resets terminal to crazy defaults

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

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 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..

ESC c

is the reset sequence as well...but that's likely too big a hammer.

Warner

thanks
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 3764 bytes --]

Re: Qemu resets terminal to crazy defaults

[Fabiano Rosas]

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.
>
> Warner
>
> thanks
>> -- PMM
>>
>>

Re: Qemu resets terminal to crazy defaults

[Dave Blanchard]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

Once it was made clear the problem was in the BIOS, it was easy to find. I've made the attached patch, but haven't yet tested it.

[-- Attachment #2: qemu-8.1.3-dont-screw-up-terminal-settings.patch --]
[-- Type: application/octet-stream, Size: 354 bytes --]

--- ./roms/seabios/src/sercon.c.orig	2023-11-21 10:49:27.000000000 -0600
+++ ./roms/seabios/src/sercon.c	2023-12-19 15:22:44.818067304 -0600
@@ -346,9 +346,4 @@
     SET_LOW(sercon_row_last, 0);
     SET_LOW(sercon_attr_last, 0);
-
-    sercon_term_reset();
-    sercon_term_no_linewrap();
-    if (clearscreen)
-        sercon_term_clear_screen();
 }
 

Re: Qemu resets terminal to crazy defaults

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 3784 bytes --]

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

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.