On Mon, Oct 06, 2025 at 03:28:55PM +0100, Daniel P. Berrangé wrote: > On Mon, Oct 06, 2025 at 04:03:17PM +0200, Gerd Hoffmann wrote: > > Starting with the edk2-stable202508 tag OVMF (and ArmVirt too) have > > optional support for logging to a memory buffer. There is guest side > > support -- for example in linux kernels v6.17+ -- to read that buffer. > > But that might not helpful if your guest stops booting early enough that > > guest tooling can not be used yet. So host side support to read that > > log buffer is a useful thing to have. > > I presume this log will contain the same kind of info that we > currently get when enabling the isa-debugcon device ?
Yes. > If so, > it will definitely make debugging easier if that has become > an 'always on' feature we can query on any guest without needing > to configure isa-debugcon devices. It's also much faster than writing to isa-debugcon > More info in devel/writing-monitor-commands.rst Thanks for the pointer. > IIUC, it is circular buffer - what size is the log capped > at currently ? Yes, it's a ring buffer. Size is configurable, default is 32 pages aka 128k. > > + /* > > + * edk2 uses this for locking access. > > + */ > > + uint64_t MemDebugLogLock; > Once the buffer is full, presumably head & tail offset will be equal > as EDK shuffles them along, overwriting oldest data. If so we will > have a potential race when reading the data, where the offsets > change between the time we read the header, and access to the log > buffer. IOW, what we think we've just read as a the oldest output, > might in fact be the very newest output. Correct. > I wonder if there is any practical way to mitigate that problem > so we don't dump misleadingly ordered logs ? There is a lock to make sure parallel access (inside edk2, when setting up SMP) doesn't corrupt the log. It is probably possible for qemu to just grab that lock while it reads the buffer. I'd expect the typical use case would be more like figuring why the machine doesn't boot in case the firmware ran into some problem early enough that reporting it to the console is not yet possible but seriously enough that it can't continue booting. The firmware typically sits in a 'hlt' loop then and doesn't write more data to the log. > Is there no better way to find the log than to trawl through > up to 4 GB of memory ? Requires coding some knowledge about OVMF internals into qemu. take care, Gerd
