[Bug 3987] Adds a new memory allocation boot service GetMemoryMapEx that carries a memory feature support bitmap.


bugzilla-daemon@...
 

https://bugzilla.tianocore.org/show_bug.cgi?id=3987

--- Comment #16 from mxu9 <min.m.xu@...> ---
(In reply to Dionna Glaze from comment #9)
I think the combination of an OsIndications bit and the self-report kernel
header bit could be a full solution, but a new OsIndications bit requires a
spec change, correct?

A. No OsIndications bit, accept all.
B. OsIndications bit set on second boot, so don't accept all.
C. No OsIndications bit, accept all.
D. OsIndications bit set on second boot, so don't accept all.
E. VMM inspects kernel binary for bit, doesn't create unaccepted memory
regions for e820.
F. VMM inspects kernel binary for bit, creates unaccepted memory regions for
e820.
It seems OsIndications is ignored in E/F, right? VMM inspects kernel binary for
the bit and then what VMM does? Does VMM pass the capability of unaccept
memmory of the kernel to FW in some way, for example, fw_cfg (QEMU talks with
FW) or TD-Hob (VMM pass information in TD-Hob to TDVF)? If this is the case, I
am thinking E/F can handle A/B/C/D as well.

Another question is that it seems the discussion is focused on whether the
kernel support unaccept-mem or not. Shall we also consider the minimal amount
of the memory that kernel needs. So that FW can accept that amount of memory
then let OS handle the left unaccept-mem.

--
You are receiving this mail because:
You are on the CC list for the bug.