mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: hpa@zytor.com
To: ron minnich <rminnich@gmail.com>, Randy Dunlap <rdunlap@infradead.org>
Cc: Matthew Garrett <mjg59@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"maintainer:X86 ARCHITECTURE..." <x86@kernel.org>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option
Date: Wed, 25 Mar 2020 10:21:39 -0700	[thread overview]
Message-ID: <F4664C3D-B6A0-4559-BEFB-59098190904D@zytor.com> (raw)
In-Reply-To: <CAP6exYLK11rhreX=6QPyDQmW7wPHsKNEFtXE47pjx41xS6O7-A@mail.gmail.com>

On March 24, 2020 9:19:01 AM PDT, ron minnich <rminnich@gmail.com> wrote:
>Subject: [PATCH 1/1] initrdmem= option to specify initrd physical
>address
>
>This patch adds the initrdmem option:
>initrdmem=ss[KMG],nn[KMG]
>which is used to specify the physical address of the initrd,
>almost always an address in FLASH. It also adds code for
>x86 to use the existing phys_init_start and
>phys_init_size variables in the kernel.
>This is useful in cases where we wish to place a kernel
>and initrd in FLASH, but there is no firmware file
>system structure in the FLASH.
>
>One such situation occurs when we have reclaimed unused FLASH
>space on UEFI systems by, e.g., taking it from the Management
>Engine. For example, on many systems, the ME is given half the
>FLASH part; not only is 2.75M of an 8M part unused; but 10.75M
>of a 16M part is unused. We can use this space to contain
>an initrd, but need to tell Linux where it is.
>
>This space is "raw": due to, e.g., UEFI limitations:
>it can not be added to UEFI firmware volumes without rebuilding
>UEFI from source or writing a UEFI device driver. We can reference it
>only as a physical address and size.
>
>At the same time, should we netboot a kernel or load it from
>GRUB or syslinux, we want to have the option of not using
>the physical address specification. Then, should we wish, it
>is easy to boot the kernel and provide an initrd; or boot the
>the kernel and let it use the initrd in FLASH. In practice this
>has proven to be very helpful as we integrate Linux into FLASH
>on x86.
>
>Hence, the most flexible and convenient path is to enable the
>initrdmem command line flag in a way that it is the last choice tried.
>
>For example, on the DigitalLoggers Atomic Pi, we burn an image into
>FLASH with a built-in command line which includes:
>initrdmem=0xff968000,0x200000
>which specifies a location and size.
>
>Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
>---
> Documentation/admin-guide/kernel-parameters.txt |  7 +++++++
> arch/x86/kernel/setup.c                         |  6 ++++++
> init/do_mounts_initrd.c                         | 13 ++++++++++++-
> 3 files changed, 25 insertions(+), 1 deletion(-)
>
>diff --git a/Documentation/admin-guide/kernel-parameters.txt
>b/Documentation/admin-guide/kernel-parameters.txt
>index c07815d230bc..9cd356958a7f 100644
>--- a/Documentation/admin-guide/kernel-parameters.txt
>+++ b/Documentation/admin-guide/kernel-parameters.txt
>@@ -1714,6 +1714,13 @@
>
>     initrd=        [BOOT] Specify the location of the initial ramdisk
>
>+    initrdmem=    [KNL] Specify a physical adddress and size from
>which
>+            to load the initrd. If an initrd is compiled in or
>+            specified in the bootparams, it takes priority
>+            over this setting.
>+            Format: ss[KMG],nn[KMG]
>+            Default is 0, 0
>+
>init_on_alloc=    [MM] Fill newly allocated pages and heap objects with
>             zeroes.
>             Format: 0 | 1
>diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>index a74262c71484..1b04ef8ea12d 100644
>--- a/arch/x86/kernel/setup.c
>+++ b/arch/x86/kernel/setup.c
>@@ -237,6 +237,9 @@ static u64 __init get_ramdisk_image(void)
>
>     ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
>
>+    if (ramdisk_image == 0) {
>+        ramdisk_image = phys_initrd_start;
>+    }
>     return ramdisk_image;
> }
> static u64 __init get_ramdisk_size(void)
>@@ -245,6 +248,9 @@ static u64 __init get_ramdisk_size(void)
>
>     ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
>
>+    if (ramdisk_size == 0) {
>+        ramdisk_size = phys_initrd_size;
>+    }
>     return ramdisk_size;
> }
>
>diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
>index dab8b1151b56..d72beda824aa 100644
>--- a/init/do_mounts_initrd.c
>+++ b/init/do_mounts_initrd.c
>@@ -28,7 +28,7 @@ static int __init no_initrd(char *str)
>
> __setup("noinitrd", no_initrd);
>
>-static int __init early_initrd(char *p)
>+static int __init early_initrdmem(char *p)
> {
>     phys_addr_t start;
>     unsigned long size;
>@@ -43,6 +43,17 @@ static int __init early_initrd(char *p)
>     }
>     return 0;
> }
>+early_param("initrdmem", early_initrdmem);
>+
>+/*
>+ * This is here as the initrd keyword has been in use since 11/2018
>+ * on ARM, PowerPC, and MIPS.
>+ * It should not be; it is reserved for bootloaders.
>+ */
>+static int __init early_initrd(char *p)
>+{
>+    return early_initrdmem(p);
>+}
> early_param("initrd", early_initrd);
>
>static int init_linuxrc(struct subprocess_info *info, struct cred *new)

Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

  reply	other threads:[~2020-03-25 17:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 23:49 ron minnich
2020-03-19 23:57 ` hpa
2020-03-20  0:50   ` ron minnich
2020-03-20  0:59     ` hpa
2020-03-20 15:39       ` ron minnich
2020-03-20 18:19       ` Matthew Garrett
2020-03-23 18:19         ` hpa
2020-03-23 18:54           ` ron minnich
2020-03-23 19:05             ` hpa
2020-03-23 19:40               ` ron minnich
2020-03-23 21:41                 ` hpa
2020-03-23 22:29                   ` ron minnich
2020-03-23 22:38                     ` ron minnich
2020-03-24 16:05                       ` ron minnich
2020-03-24 16:12                         ` Randy Dunlap
2020-03-24 16:19                           ` ron minnich
2020-03-25 17:21                             ` hpa [this message]
2020-04-27  7:35                             ` [tip: x86/boot] x86/setup: Add an initrdmem= option to specify initrd physical address tip-bot2 for Ronald G. Minnich
2020-03-25  3:30                     ` [PATCH 1/1] x86 support for the initrd= command line option H. Peter Anvin
2020-03-25 16:19                       ` ron minnich
2020-03-25 17:20                         ` hpa

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=F4664C3D-B6A0-4559-BEFB-59098190904D@zytor.com \
    --to=hpa@zytor.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@google.com \
    --cc=rdunlap@infradead.org \
    --cc=rminnich@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®