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

[Jason Thorpe <thorpej%me.com@localhost>]

So, DEC made a class of machines, “Laser” (and later, “TurboLaser”) that have an interesting architectural feature.  On these machines, the CPU modules (which might have one or two CPUs) contain the RTC and console UART devices.  The address decoding logic on these modules is such that only the RTC and UART (a Zilog 8530) devices local to that module are accessible by any given CPU.  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.

For the RTC, this is somewhat annoying, but the RTC isn’t accessed terribly often, and for about a year now there’s been code to handle this situation (by using an xcall when necessary) in the Alpha port’s “mcclock” driver.

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.

The purpose of this message is to spur a discussion about how to handle this.  One approach is to funnel all kernel printf activity to the primary CPU.  Another approach is to handle this in the console UART driver, doing xcalls as necessary.  I’m sure there are others.  Hand-waving the DDB issues for now.

-- thorpej