public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Timur Tabi <timur@codeaurora.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-efi@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Mark Salter <msalter@redhat.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 06/10] arm64: efi: add EFI stub
Date: Wed, 8 Feb 2017 17:34:38 +0000	[thread overview]
Message-ID: <20170208173438.GJ15459@leverpostej> (raw)
In-Reply-To: <a39d60da-ff74-0bcb-4a02-05cb41e58fa5@codeaurora.org>

On Wed, Feb 08, 2017 at 10:30:37AM -0700, Jeffrey Hugo wrote:
> On 2/8/2017 10:03 AM, Mark Rutland wrote:
> >On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote:
> >>On 02/08/2017 10:29 AM, Ard Biesheuvel wrote:
> >>>>>>>+       status = handle_cmdline_files(sys_table, image, cmdline_ptr,
> >>>>>>>+                                     "initrd=", dram_base + SZ_512M,
> >>>>>>>+                                     (unsigned long *)&initrd_addr,
> >>>>>>>+                                     (unsigned long *)&initrd_size);
> >>>>>
> >>>>>So I know this patch is almost three years old, but why is there a
> >>>>>512M limit on the initrd size?
> >>>>>
> >>>How do you reckon this constitutes a limit?
> >>
> >>handle_cmdline_files() calls efi_high_alloc() with that limit.  I'm
> >>still trying to understand all the details myself, but apparently
> >>our firmware and initrd need to fit within the first 512MB because
> >>of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to
> >>"~0", everything works.
> >
> >Just to check, how big is that initrd?
> >
> >I guess it's possible that there simply isn't sufficient contiguous free
> >memory in that range, even if the initrd isn't that large. Can you share
> >the EFI memory map dump from booting with efi=debug?
> >
> >We originally needed to restrict this to ensure that the kernel could
> >map the initrd (and I think the 512M restriction specifically was
> >inherited from the DTB mapping restriction). Since then, we have relaxed
> >things in the kernel, and today Documentation/arm64/booting.txt says:
> >
> >	If an initrd/initramfs is passed to the kernel at boot, it must
> >	reside entirely within a 1 GB aligned physical memory window of
> >	up to 32 GB in size that fully covers the kernel Image as well.
> >
> >... so I think the EFI stub should be able to take advantage of that
> >relaxation.
> 
> I agree.  The wrinkle I can see in this is it looks like KASLR can
> put the kernel anywhere in RAM.  How do we ensure initrd is within
> 32GB of the kernel on a system with 256 GB of RAM?

The EFI stub chose the physical location of the kernel, and should know
where it put it. The virtual location of the kernel shouldn't matter.

At some point though, this does become best-effort, unless we want a SAT
solver in the stub.

Thanks,
Mark.

  reply	other threads:[~2017-02-08 17:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 18:45 [PATCH v3 00/10] arm64: UEFI support Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 01/10] lib: add fdt_empty_tree.c Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 02/10] doc: efi-stub.txt updates for ARM Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 03/10] efi: add helper function to get UEFI params from FDT Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 04/10] arm64: Add function to create identity mappings Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 05/10] efi: Add shared FDT related functions for ARM/ARM64 Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 06/10] arm64: efi: add EFI stub Leif Lindholm
2014-04-09 14:20   ` Mark Rutland
2014-04-10 12:54     ` Mark Salter
2017-02-08 16:28   ` Timur Tabi
2017-02-08 16:29     ` Ard Biesheuvel
2017-02-08 16:35       ` Timur Tabi
2017-02-08 17:03         ` Mark Rutland
2017-02-08 17:22           ` Jeffrey Hugo
2017-02-08 17:30           ` Jeffrey Hugo
2017-02-08 17:34             ` Mark Rutland [this message]
2017-02-08 17:40           ` Ard Biesheuvel
2014-04-04 18:45 ` [PATCH v3 07/10] doc: arm64: add description of EFI stub support Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 08/10] arm64: add EFI runtime services Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 09/10] doc: arm: add UEFI support documentation Leif Lindholm
2014-04-04 18:45 ` [PATCH v3 10/10] efi/arm64: ignore dtb= when UEFI SecureBoot is enabled Leif Lindholm

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=20170208173438.GJ15459@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=jhugo@codeaurora.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msalter@redhat.com \
    --cc=timur@codeaurora.org \
    /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