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

["Gerd Hoffmann" <kraxel@redhat.com>]

On Fri, May 27, 2022 at 04:43:05AM +0200, Alexander Graf via groups.io wrote:
> I recently looked at improving the bootup performance of virtual machines
> and was amazed by the fact that there is no logging / tracing framework
> available that would give me a full picture of the Pre-OS phase including
> time stamps and boot loaders (such as grub) without writing data to the
> serial port - which taints all measurements.

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?

That will not completely kill the boot slowdown / measurement tainting
problem, but it should be an order of magnitude smaller.

Advantages:  We can leave the time stamp collection to the host, avoiding
issues like not knowing the tsc frequency in early firmware code.  You
can read the log even in case the guest doesn't boot up successfully.

>   3) Extensability to other payloads - The FPDT infrastructure considers
>      everything as owned by PerformanceLib. I would like to create a one
>      stop place for arbitrary UEFI applications to also put performance
>      measurement data.

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.

take care,
  Gerd