All of lore.kernel.org
 help / color / mirror / Atom feed
From: jeremy.linton@arm.com (Jeremy Linton)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
Date: Mon, 8 Feb 2016 10:17:09 -0600	[thread overview]
Message-ID: <56B8BF85.2060407@arm.com> (raw)
In-Reply-To: <CAKv+Gu__xLKxwAXXf=C3VxpLizjP3oADYyk0bQzQT1G-gTxFqQ@mail.gmail.com>

On 02/03/2016 08:26 AM, Ard Biesheuvel wrote:
> On 3 February 2016 at 15:22, Mark Salter <msalter@redhat.com> wrote:
>> On Tue, 2016-02-02 at 18:06 +0000, Will Deacon wrote:
>>> On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
>>>> After discussing in linux-efi with Mark, and on #armlinux with Will, this is
>>>> a proposal for dealing with initrd memory that is potentially not covered by
>>>> the linear region.
>>>>
>>>> Note that this will look slightly differently when some of the KASLR work gets
>>>> merged, but this should only affect the way we deal with the initrd if it sits
>>>> outside of the linear region.
>>>>
>>>> Mostly intended for discussion, not tested at all.
>>>
>>> Thanks Ard, this looks like a much better approach to me. Mark -- does
>>> the general idea work for you too?
>>>
>>> Will
>>
>> Yeah, much simpler. I like it in concept but am I missing something or is it
>> adding memory to the system beyond the mem= limit?
>
> Indeed. I think it is reasonable to require that if you pass both mem=
> and initrd= *and* you need your memory limit to be honored strictly,
> it is up to you to ensure that the initrd does not live in the memory
> you are throwing away.
>
>> But even that may not be
>> a big deal. And I need to look at the KASLR work and understand the issues
>> with it and mem= if any. I'm traveling right now and can't really try it out
>> until tomorrow...
>>
>
> No worries. My estimation is that Will is not going to take this as a
> fix anyway, so we have plenty of time to test and/or discuss


I needed these patches to successfully boot a JunoR2 with a recent 
tianocore firmware.

Thanks,

  reply	other threads:[~2016-02-08 16:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-02 17:56 [RFC PATCH 0/3] arm64 initrd mapping/relocation Ard Biesheuvel
2016-02-02 17:56 ` [RFC PATCH 1/3] memblock: add routine to clear the MEMBLOCK_NOMAP flag for a region Ard Biesheuvel
2016-02-02 17:56 ` [RFC PATCH 2/3] arm64: add the initrd region to the linear mapping explicitly Ard Biesheuvel
2016-02-02 17:56 ` [RFC PATCH 3/3] arm64: remove the now unneeded relocate_initrd() Ard Biesheuvel
2016-02-02 18:06 ` [RFC PATCH 0/3] arm64 initrd mapping/relocation Will Deacon
2016-02-02 21:39   ` Mark Langsdorf
2016-02-03 14:22   ` Mark Salter
2016-02-03 14:26     ` Ard Biesheuvel
2016-02-08 16:17       ` Jeremy Linton [this message]
2016-02-02 21:39 ` Mark Langsdorf
2016-02-03  8:42   ` Ard Biesheuvel

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=56B8BF85.2060407@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.