Re: [RFC/RFT PATCH 0/6] ARM: p2v: reduce min alignment to 2 MiB

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Sun, Sep 20, 2020 at 09:50:30AM +0200, Ard Biesheuvel wrote:
> On Sun, 20 Sep 2020 at 01:49, Nicolas Pitre <nico@fluxnic.net> wrote:
> >
> > On Fri, 18 Sep 2020, Ard Biesheuvel wrote:
> >
> > > This series is inspired by Zhei Len's series [0], which updates the
> > > ARM p2v patching code to optionally support p2v relative alignments
> > > of as little as 64 KiB.
> > >
> > > Reducing this alignment is necessary for some specific Huawei boards,
> > > but given that reducing this minimum alignment will make the boot
> > > sequence more robust for all platforms, especially EFI boot, which
> > > no longer relies on the 128 MB masking of the decompressor load address,
> > > but uses firmware memory allocation routines to find a suitable spot
> > > for the decompressed kernel.
> > >
> > > This series is not based on Zhei Len's code, but addresses the same
> > > problem, and takes some feedback given in the review into account:
> > > - use of a MOVW instruction to avoid two adds/adcs sequences when dealing
> > >   with the carry on LPAE
> > > - add support for Thumb2 kernels as well
> > > - make the change unconditional - it will bit rot otherwise, and has value
> > >   for other platforms as well.
> > >
> > > The first four patches are general cleanup and preparatory changes.
> > > Patch #5 implements the switch to a MOVW instruction without changing
> > > the minimum alignment.
> > > Patch #6 reduces the minimum alignment to 2 MiB.
> > >
> > > Tested on QEMU in ARM/!LPAE, ARM/LPAE, Thumb2/!LPAE and Thumb2/LPAE modes.
> >
> > At this point I think this really ought to be split into a file of its
> > own... and maybe even rewritten in C. Even though I wrote the original
> > code, I no longer understand it without re-investing time into it. But
> > in either cases the whole of head.S would need to have its registers
> > shuffled first to move long lived values away from r0-r3,ip,lr to allow
> > for standard function calls.
> >
> 
> I agree with that in principle, however, running C code with a stack
> with the MMU off is slightly risky.

It's more than "slightly".  C code has literal addresses, which are raw
virtual addresses.  These are meaningless with the MMU off.

I guess one could correct the various pointers the code would read, but
you could not directly access any variable (as that involves
dereferencing a virtual address stored in the function's literal pool.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!