Re: [PATCH v2 0/4] ARM: decompressor: use by-VA cache maintenance for v7 cores

[Ard Biesheuvel <ardb@kernel.org>]

On Fri, 21 Feb 2020 at 14:42, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 21 Feb 2020 at 14:35, Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 20/02/2020 6:08 pm, Ard Biesheuvel wrote:
> > > (+ Arnd)
> > >
> > > On Wed, 19 Feb 2020 at 10:43, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >>
> > >> While making changes to the EFI stub startup code, I noticed that we are
> > >> still doing set/way maintenance on the caches when booting on v7 cores.
> > >> This works today on VMs by virtue of the fact that KVM traps set/way ops
> > >> and cleans the whole address space by VA on behalf of the guest, and on
> > >> most v7 hardware, the set/way ops are in fact sufficient when only one
> > >> core is running, as there usually is no system cache. But on systems
> > >> like SynQuacer, for which 32-bit firmware is available, the current cache
> > >> maintenance only pushes the data out to the L3 system cache, where it
> > >> is not visible to the CPU once it turns the MMU and caches off.
> > >>
> > >> So instead, switch to the by-VA cache maintenance that the architecture
> > >> requires for v7 and later (and ARM1176, as a side effect).
> > >>
> > >> Changes since v1:
> > >> - include the EFI patch that was sent out separately before (#1)
> > >> - split the preparatory work to pass the region to clean in r0/r1 in a EFI
> > >>    specific one and one for the decompressor - this way, the first two patches
> > >>    can go on a stable branch that is shared between the ARM tree and the EFI
> > >>    tree
> > >> - document the meaning of the values in r0/r1 upon entry to cache_clean_flush
> > >> - take care to treat the region end address as exclusive
> > >> - switch to clean+invalidate to align with the other implementations
> > >> - drop some code that manages the stack pointer value before calling
> > >>    cache_clean_flush(), which is no longer necessary
> > >> - take care to clean the entire region that is covered by the relocated zImage
> > >>    if it needs to relocate itself before decompressing
> > >>
> > >> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm32-efi-cache-ops
> > >>
> > >
> > > Adding my own data point here: with these patches, I can reproducibly
> > > boot on the SynQuacer platform (24x Cortex-A53 + GICv3 + L3 system
> > > cache) until the point where /init is loaded, after which it hangs
> > > (see below), whereas without them, it always crashes early with weird,
> > > unreproducible errors, if it even makes it far enough through the
> > > decompressor to produce any earlycon output.
> > >
> > > There is some other weird stuff going on, but this is unlikely to be
> > > related to cache maintenance:
> > > - multiple occurrences of
> > >     OF: translation of DMA address(0) to CPU address failed node(...)
> >
> > FWIW that implies a "dma-ranges" property in the wrong place in the DT -
> > if you copied the now-gone Juno example of placing one directly in the
> > root node, that was bogus, sorry.
> >
>
> OK, so where should it be instead? Are you saying it is now required
> to have a /soc or /smb node that contains all the device nodes?
>

Never mind - I'll just drop "dma-ranges" from the root node entirely.