All of lore.kernel.org
 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 [PATCH 1/1] x86 support for the initrd= command line option 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 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.