Re: [edk2-devel] [PATCH 00/12] Introduce Bootlog DEBUG() output

["Benjamin Doron" <benjamin.doron00@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

On Wed, Jun 1, 2022 at 05:33 AM, Gerd Hoffmann wrote:

> 
> Hmm. Maybe it's time to tackle the log performance problem for virtual
> machines? Create a debug log device with DMA support, so we don't need
> a vmexit for every single character we want log?

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 ( https://github.com/benjamindoron/edk2/commit/db888a928c1c6fc94f6a7670f3402718c10c01d2 ). It's WIP, modelled after the simple coreboot ringbuffer and is missing tracing facilities.

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).

> 
> How does that relate to coreboot? coreboot has logging-to-memory too.
> Not sure what the state is, there have been discussions on the coreboot
> list about changing that from a pure text log to something structed with
> timestamps a while back. Don't know whenever this did actually happen.
> 
> So, when adding logging-to-memory to edk2 it surely make sense to
> coordinate that with coreboot, so we'll have both coreboot and edk2 logs
> there in case edk2 runs as coreboot payload.

I'm working on getting a SerialPortLib that logs to CBMEM merged. It's on the list at the moment.

Some comments on DebugLibBootlog:
- It's possible to support ASSERTs. If PcdDebugPropertyMask & 0x31 == 0x01, then non-fatal ASSERTs are logged. As a DebugLib, this would require handling in `DebugAssert()`.
- 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.

Regards,
Benjamin

[-- Attachment #2: Type: text/html, Size: 2157 bytes --]