Re: What if the console device is only accessible from one CPU in a multiprocessor system?

[Christoph Badura <bad%bsd.de@localhost>]

On Tue, Mar 04, 2025 at 01:26:42PM -0800, Jason Thorpe wrote:
> The firmware selects which CPU module gets to boot the system (the
> criteria used is unimportant here), and the UART on that module is
> connected to the console port and the RTC on that module is the
> authoritative RTC for the system.
>
> Obviously, this is a lot more problematic for the console device.  We
> currently have no restrictions in the kernel overall around which CPU
> gets to access the console device for printing messages, and don’t
> even get me started on how weird this all gets with DDB.

My first thought over morning coffe was to add a thin layer on the
cnputc/cngetc/cnpollc interface level.  Basically have a stack of
cn_tabs (only the necessary parts perhaps).  On the Laser/TurboLaser
machines have "virtual" cnputc/cngetc/cnpollc that, on the boot CPU,
calls the "real" cnputc/cngetc that frobs the hardware and, on the other
CPUs, xcalls to the boot CPU.  I presume you can easily identify the
boot CPU.  I don't see a way around the xcall.

The "thin layer" may come in handy when we want to deal with multiple
devices acting as console like e.g. Linux has it.  There you can have
console on e.g. frame buffer and serial simultaneously.

I'm surprised you expect weirdness with DDB.  I thought DDB runs on the
boot CPU and pauses all other CPUs.  Doing xcalls to the other CPUs for
stack traces etc.  I.e. it's a non-issue for DDB.

I did a bit of nxr'ing on cnputc and on subr_prf.c but that quickly
turned into a maze of twisty little passages to large for my short term
memory.  The main thing I remember is that kprintf ends up cnputc'ing
every single character.  Sending a bunch of characters in an xcall might
be less overhead.

You are looking for an excuse to pull out the rototiller, aren't you?  :-)

--chris