Skip to content

RFC arm64 initrd mapping/relocation

Jeremy Linton linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 3 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 3 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC PATCH 0/3] arm64 initrd mapping/relocation
Quoted 26 lines · Ard Biesheuvel
Quoted 12 lines · Mark Salter
Quoted 11 lines · Will Deacon
Quoted 9 lines · Ard Biesheuvel

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.

Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 5 lines

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,