OvmfPkg/PlatformDxe: register log buffer as efi config table

[kraxel]

If a memory debug log buffer is present, register the buffer location as
config table so the OS can find and show it.

Signed-off-by: Gerd Hoffmann [email protected]

[kraxel]

@ajyoung-oracle

[kraxel]

linux kernel side of this:
https://gitlab.com/kraxel/linux/-/commit/4d049a97f751355eb7e4065cf36beedddb733442

[ajyoung-oracle]

linux kernel side of this: https://gitlab.com/kraxel/linux/-/commit/4d049a97f751355eb7e4065cf36beedddb733442

Hi Gerd, Looking the ovmf_log_read() function for this patch, it seems it's not quite complete.
The algorithm to display (or in this case copy) the memory debug log messages in time order is (copied from from the EDK2 code):
//
// Maintain a circular (wrap around) log buffer
// NOTES:
// tail always points to next available slot to populate
// Algorithm to process/display strings from buffer in time order:
// 1. head==tail indicates empty buffer
// 2. if (head < tail), process from head (tail-head) bytes
// 3. if (head > tail), process from head (bufend-head) bytes
// process from bufstart (tail-bufstart) bytes

In case#3, where the buffer has wrapped (due to being circular), I believe (if I am reading the code right) ovmf_log_read() is not doing the second part - i.e. "process from bufstart (tail-bufstart) bytes". I think you will need a second memcpy() call for this wrapped case to get the last messages (from the start of the buffer through the tail). You can double check me of course.

[kraxel]

I think you will need a second memcpy() call for this wrapped case to get the last messages (from the start of the buffer through the tail). You can double check me of course.

Nope. ovmf_read_log() is called repeatedly (with page-sized buffer) until it returns 0 to indicate it has no more data. That'll also takes care of the wrapping case.