RFC arm64 initrd mapping/relocation
Get series with b4
b4 am [email protected]Versions newest first
- 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.
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,