From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [PATCH 00/12] Introduce Bootlog DEBUG() output To: Gerd Hoffmann ,devel@edk2.groups.io From: "Benjamin Doron" X-Originating-Location: Richmond Hill, Ontario, CA (24.52.200.135) X-Originating-Platform: Linux Firefox 100 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 01 Jun 2022 09:58:40 -0700 References: <20220601093352.hx4w447n7myc7re6@sirius.home.kraxel.org> In-Reply-To: <20220601093352.hx4w447n7myc7re6@sirius.home.kraxel.org> Message-ID: <30076.1654102720972535874@groups.io> Content-Type: multipart/alternative; boundary="tI1iI5kdV9ye1cCYTspO" --tI1iI5kdV9ye1cCYTspO Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 1, 2022 at 05:33 AM, Gerd Hoffmann wrote: >=20 > 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 dev= elopers perform debugging (possibly via a serial port), but I developed a l= ibrary stack similar to this one to help me with GSoC last year ( https://g= ithub.com/benjamindoron/edk2/commit/db888a928c1c6fc94f6a7670f3402718c10c01d= 2 ). 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 s= tatus code for the debug messages). >=20 > 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. >=20 > 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 t= he list at the moment. Some comments on DebugLibBootlog: - It's possible to support ASSERTs. If PcdDebugPropertyMask & 0x31 =3D=3D 0= x01, then non-fatal ASSERTs are logged. As a DebugLib, this would require h= andling 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 wo= uld be more complicated. I stopped working on it when the return-on-investm= ent was too low. Regards, Benjamin --tI1iI5kdV9ye1cCYTspO Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 do= n'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 dev= elopers perform debugging (possibly via a serial port), but I developed a l= ibrary stack similar to this one to help me with GSoC last year (https://github.com/benjamin= doron/edk2/commit/db888a928c1c6fc94f6a7670f3402718c10c01d2). It's WIP, = modelled after the simple coreboot ringbuffer and is missing tracing facili= ties.

Regardless, having a true complement to PcdStatusCodeUseSe= rial would often be helpful, I suspect (presently, PcdStatusCodeUseMemory o= nly logs the PI status code for the debug messages).
How does that relate to coreboot? coreboot has logging-to-memor= y 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 st= ructed with
timestamps a while back. Don't know whenever this did actu= ally happen.

So, when adding logging-to-memory to edk2 it surely= make sense to
coordinate that with coreboot, so we'll have both coreb= oot 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 t= he list at the moment.

Some comments on DebugLibBootlog:
- = It's possible to support ASSERTs. If PcdDebugPropertyMask & 0x31 =3D=3D= 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 worki= ng on it when the return-on-investment was too low.

Regards,
Benjamin --tI1iI5kdV9ye1cCYTspO--