On Wed, Jul 31, 2019 at 11:58 AM, Laszlo Ersek wrote:

> 
> I'm sure I'm misremembering parts of this story (from several years
> distance), the moral is that debugging in a multiprocessing environment
> may easily require its own dedicated infrastructure. In edk2, we don't
> have anything like that, I think. Could we build it, sufficiently
> generally? Like, prepare a log buffer for each CPU before calling
> StartupAllAps(), log only to that buffer during the concurrent
> execution, and finally dump the buffers? I guess if we don't *reach* the
> "finally" part, we could still dump the RAM and investigate the log
> buffers that way... Dumping the RAM is certainly an option for virtual
> machines, but it might be viable for physical setups too (JTAG, debug
> agent... dunno).
> 
> Sorry about the wild speculation :)

Laszlo,

The wild speculation is good.  In fact, I would say it should get wilder still.  Consider systems with multiple CPU sockets contending for control of a single debug channel.  There is no edk2 solution for granting and revoking control of debug between sockets.  Worse still, early enough in boot there may be no coherent memory where the sockets could put log buffers, so we can't charge one of them with dumping all the output.  Instead it becomes necessary to solve the coordination problem more directly.

I actually have this problem, and a functional-but-not-pretty solution.  I'd like to see an edk2 supported way to handle it.  What I've got now funnels all such debug through the report status code infrastructure and replaces the serial port status code handler with an implementation that's gated by a hardware-backed coordination primitive.  I don't see a way around putting a hardware-backed primitive in there somewhere if sockets without shared memory are to be supported, but the rest of the details are open to alternatives.

A solution would need to define one-or-more coordination primitives via library class and create some way to enable those libraries to gate debug.  This can work for sockets or APs at any time, while buffer-and-dump can only work on sockets if they've already got coherent memory.  Of course buffer-and-dump has other desirable properties and doesn't require anything from hardware, so maybe we want to enable both things at the levels they work/make sense.

While I'm blathering about debug, I do not see a downside to making MAX_DEBUG_MESSAGE_LENGTH a fixed at build PCD.  It's currently #define'd in a variety of places, which in my opinion is just asking for trouble.

Does anybody have any other cans of worms to open on the broadening-debug-infrastructure front?

Thanks,
-Michael