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

Hi,
On 07/20/19 at 03:52pm, Sai Praneeth Prakhya wrote:
> Hi All,
> 
> Disclaimer:
> 1. Please note that this discussion is x86 specific
> 2. Below stated things are my understanding about kernel and I could have
> missed somethings, so please let me know if I understood something wrong.
> 3. I have focused only on memblock here because if I understand correctly,
> memblock is the base that feeds other memory management subsystems in kernel
> (like the buddy allocator).
> 
> 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.

> 
> 2. Why doesn't the kernel have "add_efi_memmap" by default? From the commit
> "200001eb140e: x86 boot: only pick up additional EFI memmap if add_efi_memmap
> flag", I didn't understand why the decision was made so. Shouldn't we give
> more preference to EFI Memory map rather than E820 table as it's the latest
> and E820 is legacy?
> 
> 3. Why isn't kernel checking that both the tables E820 table and EFI Memory
> Map are in sync i.e. is there any *possibility* that a buggy BIOS could report
> a region as usable in E820 table and as reserved in EFI Memory Map?
> 
> [1] 
> https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/setup.c#L1106
> [2] 
> https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/e820.c#L1265
> [3] 
> https://elixir.bootlin.com/linux/latest/source/arch/x86/platform/efi/efi.c#L129
> 
> Regards,
> Sai
> 

Thanks
Dave

  reply	other threads:[~2019-07-23  8:10 UTC|newest]

Thread overview: 7+ 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-20 22:52 ` Sai Praneeth Prakhya
2019-07-23  8:09 ` Dave Young [this message]
2019-07-23 17:11   ` Prakhya, Sai Praneeth
2019-07-23 21:38 ` Ricardo Neri
2019-07-23 22:01   ` Sai Praneeth Prakhya
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=20190723080949.GB9859@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --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 \
    --cc=sai.praneeth.prakhya@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.