Messages in this thread | | | From | Ard Biesheuvel <> | Date | Thu, 4 Feb 2021 15:25:20 +0100 | Subject | Re: next/master bisection: baseline.login on rk3288-rock2-square |
| |
On Thu, 4 Feb 2021 at 15:09, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Thu, Feb 04, 2021 at 12:26:44PM +0000, Marc Zyngier wrote: > > I agree. With set/way CMOs, there is no way to reach the PoC if > > it beyond the system cache, leading to an unbootable kernel. > > This is actually pretty well documented in the architecture, > > and it did bite us for the first time on XGene-1, 7 years ago. > > That may be, however we still do set/way maintenance to invalidate > the L1 cache as that is required for ARMv7 to place the cache into > a known state, as stated by the architecture reference manual. >
Getting a certain cache at a certain level into a known state is a valid use of set/way ops, and is simply unnecessary when running under virtualization, but doesn't do any harm.
Pushing contents of the cache hierarchy to main memory is *not* a valid use of set/way ops, and so there is no point in pretending that set/way ops will produce the same results as by-VA ops. Only the by-VA ops give the architectural guarantees that we rely on for correctness.
> Arguably, that should be done by firmware, but when starting > secondary CPUs, there are platforms out there which do not bring > the L1 cache to a defined state. So we are pretty much stuck with > doing set/way operations during CPU initialisation in the main > kernel. >
Indeed. And this is unfortunate, but not the end of the world.
> If ARMv8 decides that this is not supportable, then that's a matter > for ARMv8 to address without impacting the requirements of ARMv7. >
I'm not sure what you mean here. The v7 architecture is crystal clear about the difference between set/way ops (managing a single cache), and by-VA ops (managing the 'cachedness' state of a memory region). The semantics are radically different, regardless of v7 vs v8 or AArch32 vs AArch64.
| |