On Wed, Jun 1, 2022 at 05:33 AM, Gerd Hoffmann wrote:<br />
<blockquote>Hmm. Maybe it's time to tackle the log performance problem for virtual<br />machines? Create a debug log device with DMA support, so we don't need<br />a vmexit for every single character we want log?</blockquote>
Of course, that doesn't work for native systems. I don't know how other developers perform debugging (possibly via a serial port), but I developed a library stack similar to this one to help me with GSoC last year (<a href="https://github.com/benjamindoron/edk2/commit/db888a928c1c6fc94f6a7670f3402718c10c01d2" target="_blank" rel="noopener">https://github.com/benjamindoron/edk2/commit/db888a928c1c6fc94f6a7670f3402718c10c01d2</a>). It's WIP, modelled after the simple coreboot ringbuffer and is missing tracing facilities.<br /><br />Regardless, having a true complement to PcdStatusCodeUseSerial would often be helpful, I suspect (presently, PcdStatusCodeUseMemory only logs the PI status code for the debug messages).<br />
<blockquote>How does that relate to coreboot? coreboot has logging-to-memory too.<br />Not sure what the state is, there have been discussions on the coreboot<br />list about changing that from a pure text log to something structed with<br />timestamps a while back. Don't know whenever this did actually happen.<br /><br />So, when adding logging-to-memory to edk2 it surely make sense to<br />coordinate that with coreboot, so we'll have both coreboot and edk2 logs<br />there in case edk2 runs as coreboot payload.</blockquote>
I'm working on getting a SerialPortLib that logs to CBMEM merged. It's on the list at the moment.<br /><br />Some comments on DebugLibBootlog:<br />- It's possible to support ASSERTs. If PcdDebugPropertyMask &amp; 0x31 == 0x01, then non-fatal ASSERTs are logged. As a DebugLib, this would require handling in `DebugAssert()`.<br />- SMM-phase logging can be implemented, but I'm not convinced that sharing DXE's buffer is entirely safe. Using SMM communicate could be safer, but would be more complicated. I stopped working on it when the return-on-investment was too low.<br /><br />Regards,<br />Benjamin