[PATCH v12 08/16] arm64/kexec: Add core kexec support
Mark Rutland
mark.rutland at arm.com
Thu Dec 3 08:06:20 PST 2015
On Wed, Dec 02, 2015 at 01:08:33PM -0800, Geoff Levand wrote:
> Hi Mark,
>
> On Tue, 2015-12-01 at 19:03 +0000, Mark Rutland wrote:
> > You can validly perform maintenance while the cache may allocate for a
> > region of memory, it's just that afterwards the cache may hold a clean
> > entries for that region.
> >
> > You can clean/clean+invalidate to push data to the PoC, or you can
> > invalidate/clean+invalidate to ensure that no asynchronous writebacks
> > occur later (so long as you do not make a cacheable write to said
> > cacheline).
> >
> > The only thing that you cannot guarantee is that there is not some clean
> > cacheline allocated for a region of memory to which cacheable accesses
> > may be performed.
> >
> > Note that the kernel only requires its Image to be clean to the PoC. So
> > long as this is true, we know that there will not be asynchrnoous
> > writebacks, and can invalidate as necessary as part of the boot process.
I've realised that my wording here is somewhat confusing.
When I say "clean to the PoC", I mean that for a given PA the cache can
either:
* Not hold an entry (i.e. be invalid).
* Hold a clean entry, where the data is identical to that at the PoC.
> In v10, which worked for Mustang and Qualcomm, we had:
>
> clean+invalidate to PoC all source pages
> disable d-cache
> loop {
> invalidate to PoC destination page
> copy page source->destination
> }
> enter new image
>
> In v11 I changed this, and it did not work for those platforms:
>
> clean+invalidate to PoC all source pages
> clean+invalidate to PoC all destination pages
> disable d-cache
> loop {
> copy page source->destination
> }
> enter new image
>
> Based on your comments above I would think both should work OK.
No.
In the latter case, clean lines can be allocated before cacheable data
accesses are inhibited. So stale clean lines can shadow the data copied
via non-cacheable accesses.
While the cache is clean, it isn't clean to the PoC.
Thanks,
Mark.
More information about the linux-arm-kernel
mailing list