Re: Qemu resets terminal to crazy defaults

[BALATON Zoltan]

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