Re: [edk2-devel] [PATCH 2/2] OvmfPkg/PlatformPei: prefer etc/e820 for memory detection

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

On Wed, Aug 25, 2021 at 09:24:43AM +0000, Yao, Jiewen wrote:
> Hi
> Would you please follow EDKII process?
> 1) File an EDKII Bugzilla.

Ok, will do.

> 2) CC all reviewers in OVMF package.

Is there some way to automate this?

I see there is BaseTools/Scripts/GetMaintainer.py, but the script wants
a commit hash not a patch file as argument, so I can't hook it into 'git
send-email'.

> Please also describe what the reason of change, what is the benefit we
> can get from the change?
> 
> I just feel it is confusing. Previously, the data is consistent from
> CMOS. Now, we have two ways to get one data from different sources.

It is *not* consistent from CMOS.  CMOS is only used for memory below 4G
whereas the etc/e820 fw_cfg file is used for memory above 4G.  So this
patch actually makes things more consistent.

> Please help me understand:
> 
> A) What if the data are different from different source?
>
> B) Why we choose to trust E820 at first, the CMOS? Not verse versa.

e820 is the newer and more capable interface, specifically cmos can
handle at most 1TB of memory (which is the reason why e820 is already
used to detect high memory).

> C) If we trust E820 (in B), then why we need go back to CMOS, if LowMemorySize is 0?

Backward compatibility with old qemu versions.  etc/e820 is available
in qemu version 1.7 (released Nov 2013) and newer.

Does OVMF have any policy for backward compatibility?  If breaking
compatibility with qemu versions that old is acceptable I happily
delete any CMOS access from qemu PlatformPei and throw an assert()
instead.

take care,
  Gerd