On Mon, 13 Apr 2020 at 18:41, Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> wrote: > > On Mon, Apr 13, 2020 at 06:21:30PM +0200, Ard Biesheuvel wrote: > > The EFI stub in the ARM kernel runs in the context of the firmware, which > > means it runs with the caches and MMU on. Currently, we relocate the zImage > > so it appears in the first 128 MiB, disable the MMU and caches and invoke > > the decompressor via its ordinary entry point. However, since we can pass > > the base of DRAM directly, there is no need to relocate the zImage, which > > also means there is no need to disable and re-enable the caches and create > > new page tables etc. > > > > This simplification is implemented by patch #5. Patches #1 - #4 are > > prerequisite changes to permit the decompressor to execute from the > > offset chosen by the UEFI firmware. > > Why? The decompressor is already fully relocatable, so this doesn't > explain why all these changes breaking up the single place where data > is stored into multiple smaller pieces, making the code more complex > is really necessary. To me, this seems ot be change for change sake. > Please refer to patch #3 for the explanation. The EFI stub will no longer enter the decompressor startup code at the top, but jump straight to the 'wont_overwrite' label. Most of the contents of LC0 are never used before that point, so its load can easily be deferred until afterwards. If you look carefully, you'll notice that that by itself simplifies the code, because we no longer need to stack/unstack those registers either. So I would argue that reducing the liveness scope of r0, r2, r3, r11 and r12, and deferring their initialization to the point where their values are actually needed is an improvement in itself, regardless of whether the EFI stub simplification in patch #5 depends on it or not.
