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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90125): https://edk2.groups.io/g/devel/message/90125 Mute This Topic: https://groups.io/mt/91368904/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
