Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use qemu's virtconsole for the serial console #2834

Merged
merged 3 commits into from
Jul 4, 2024

Conversation

DaanDeMeyer
Copy link
Contributor

edk2 now has a virtio serial driver so let's switch to virtconsole
for the serial console as it's significantly faster compared to the
old ISA serial console.

All the latest releases of distributions now have a systemd stub
that knows how to read extra kernel command line arguments from
SMBIOS (It was backported to CentOS Stream 9), so let's drop the
default kernel command line and rely completely on passing the
console to use via SMBIOS.

This makes sure that users trying to deploy our images on bare metal
have a working console. Users that want to access the system via the
serial console will have to add the required console= argument
themselves.
It cannot be installed on powerpc or s390x.
edk2 now has a virtio serial driver so let's switch to virtconsole
for the serial console as it's significantly faster compared to the
old ISA serial console.
@teknoraver
Copy link
Contributor

I confirm it works:

[root@fedora ~]# w
 17:53:36 up 0 min,  3 users,  load average: 0.18, 0.06, 0.02
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
root     hvc0      17:53    0.00s  0.03s  0.01s w

@teknoraver
Copy link
Contributor

And it's fast:

[root@fedora ~]# time hexdump -vC -n200000 /dev/zero

real	0m0.451s
user	0m0.029s
sys	0m0.418s

Copy link
Contributor

@behrmann behrmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful.

@behrmann behrmann merged commit a4cbfdd into systemd:main Jul 4, 2024
30 of 32 checks passed
@rpardini
Copy link

rpardini commented Nov 5, 2024

While this does indeed work, for images targeting ttyS0 or ttyAMA0 as (real/physical) consoles, this breaks the autologin feature on those consoles (tty1 still works). I guess at a certain point (eg, Rockchip devices and their console on ttyS2) it makes more sense to make autologin consoles configurable somehow. Should I open an issue about this?

@DaanDeMeyer
Copy link
Contributor Author

While this does indeed work, for images targeting ttyS0 or ttyAMA0 as (real/physical) consoles, this breaks the autologin feature on those consoles (tty1 still works). I guess at a certain point (eg, Rockchip devices and their console on ttyS2) it makes more sense to make autologin consoles configurable somehow. Should I open an issue about this?

You can configure autologin with systemd credentials these days on a per tty basis. I would always do that instead of the autologin setting. I'll probably remove it at some point.

@marc-hb
Copy link

marc-hb commented Feb 11, 2025

You can configure autologin with systemd credentials these days on a per tty basis. I would always do that instead of the autologin setting. I'll probably remove it at some point.

marc-hb added a commit to marc-hb/run_qemu that referenced this pull request Feb 12, 2025
Until mkosi v24 commit c236c9f7b9c82d3, `mkosi --autologin` used to be
applied to four devices: console, tty1, ttyS0 and one
architecture-dependent device.

mkosi has some QEMU features of its own to boot the image. run_qemu.sh
never used any of that. We should probably try (some of) it in the
future but I digress. In that mkosi commit, `mkosi/qemu.py` (which we
don't use) stopped using `ttyS0` and replaced it with the faster
`/dev/hvc0` instead. The image building code (which we DO use!) was
updated correspondingly without caring about backwards compatibility and
dropped ttyS0 on the floor. Someone noted this in
systemd/mkosi#2834 and the recommendation was to
switch to systemd credentials: exactly what this commit does. The mkosi
maintainer also expressed the possible removal of `--autologin` in the
future.

Pros:
- Completely removes the autologin dependency on the changing mkosi
  behavior. Compatible with any mkosi version.
- Applies to all terminals, zero hardcoded name.
- Simpler, clearer and more direct implementation: zero configuration file!
- More dynamic: changes and tests do not require rebuilding anything.

Cons:
- Requires systemd v251 or above (May 2022)
- Applies to all terminals but could be more selective when using
  "per-instance" systemd credentials added in v257 (December 2024)

Signed-off-by: Marc Herbert <[email protected]>
stellarhopper pushed a commit to pmem/run_qemu that referenced this pull request Feb 12, 2025
Until mkosi v24 commit c236c9f7b9c82d3, `mkosi --autologin` used to be
applied to four devices: console, tty1, ttyS0 and one
architecture-dependent device.

mkosi has some QEMU features of its own to boot the image. run_qemu.sh
never used any of that. We should probably try (some of) it in the
future but I digress. In that mkosi commit, `mkosi/qemu.py` (which we
don't use) stopped using `ttyS0` and replaced it with the faster
`/dev/hvc0` instead. The image building code (which we DO use!) was
updated correspondingly without caring about backwards compatibility and
dropped ttyS0 on the floor. Someone noted this in
systemd/mkosi#2834 and the recommendation was to
switch to systemd credentials: exactly what this commit does. The mkosi
maintainer also expressed the possible removal of `--autologin` in the
future.

Pros:
- Completely removes the autologin dependency on the changing mkosi
  behavior. Compatible with any mkosi version.
- Applies to all terminals, zero hardcoded name.
- Simpler, clearer and more direct implementation: zero configuration file!
- More dynamic: changes and tests do not require rebuilding anything.

Cons:
- Requires systemd v251 or above (May 2022)
- Applies to all terminals but could be more selective when using
  "per-instance" systemd credentials added in v257 (December 2024)

Signed-off-by: Marc Herbert <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants