linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
To: Dave Young <dyoung@redhat.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"rppt@linux.ibm.com" <rppt@linux.ibm.com>,
	"pj@sgi.com" <pj@sgi.com>
Subject: RE: Why does memblock only refer to E820 table and not EFI Memory Map?
Date: Tue, 23 Jul 2019 17:11:28 +0000	[thread overview]
Message-ID: <FFF73D592F13FD46B8700F0A279B802F4F94B2C6@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <20190723080949.GB9859@dhcp-128-65.nay.redhat.com>

> > On x86 platforms, there are two sources through which kernel learns
> > about physical memory in the system namely E820 table and EFI Memory
> > Map. Each table describes which regions of system memory is usable by
> > kernel and which regions should be preserved (i.e. reserved regions
> > that typically have BIOS code/data) so that no other component in the
> > system could read/write to these regions. I think they are duplicating
> > the information and hence I have couple of questions regarding these
> >
> > 1. I see that only E820 table is being consumed by kernel [1] (i.e.
> > memblock subsystem in kernel) to distinguish between "usable" vs "reserved"
> regions.
> > Assume someone has called memblock_alloc(), the memblock subsystem
> > would service the caller by allocating memory from "usable" regions
> > and it knows this *only* from E820 table [2] (it does not check if EFI
> > Memory Map also says that this region is usable as well). So, why
> > isn't the kernel taking EFI Memory Map into consideration? (I see that
> > it does happen only when "add_efi_memmap" kernel command line arg is
> > passed i.e. passing this argument updates E820 table based on EFI
> > Memory Map) [3]. The problem I see with memblock not taking EFI Memory
> > Map into consideration is that, we are ignoring the main purpose for which EFI
> Memory Map exists.
> 
> https://blog.fpmurphy.com/2012/08/uefi-memory-v-e820-memory.html
> Probably above blog can explain some background.

Thanks a lot! Dave. The link was helpful, it did explain that Linus and HPA were 
not very happy with EFI and things were going good with E820 and hence it was given 
more preference compared to EFI.

But sadly, I am not 100% convinced yet :( (just my thoughts)
This decision was made a decade ago when EFI wasn't stable. Now that UEFI is the defacto 
on most of the x86 platforms (and since I believe UEFI is getting better) I am still unable to 
digest that kernel throws away EFI Memory Map (unless explicitly asked by "add_efi_memap")

Regards,
Sai

  reply	other threads:[~2019-07-23 17:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-20 22:52 Why does memblock only refer to E820 table and not EFI Memory Map? Sai Praneeth Prakhya
2019-07-23  8:09 ` Dave Young
2019-07-23 17:11   ` Prakhya, Sai Praneeth [this message]
2019-07-23 21:38 ` Ricardo Neri
2019-07-23 22:01   ` Sai Praneeth Prakhya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FFF73D592F13FD46B8700F0A279B802F4F94B2C6@ORSMSX114.amr.corp.intel.com \
    --to=sai.praneeth.prakhya@intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pj@sgi.com \
    --cc=rppt@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).