Do you need a dsb here to ensure any prior stores to the image have completed?

Why are you invalidating the cache? It looks like this is the image we are about to branch to, so I would expect it be a cpu_dcache_wbinv_range.

This can be a br

Do we need a BTI target here?

Could also be a br as the next instruction isn't useful

Does this need __dead2?

I don't think so. I already did the cpu_dcache_wbinv_range() (via cpu_dcache_sync) at load time, so it's stable now (wired memory, so can't have paged out).

I copy the image with the cache disabled, so I need to invalidate the cache to make sure anyone else participating in the cache protocol invalidates their copy (empirically it looks like the CPUs participate in the protocol even when their cache is disabled).

Probably.

I ran into problems testing on my M3 MBP, where it faulted because apparently br would only work with x16, or such like that (it's been a few months). Pointer authentication or something.

I assume you mean cpu_flush_dcache.

You probably don't need to set ATTR_S1_GP, it's for BTI.

It will be BTI related, if the target has the GP bit in the page table it will need the correct bti instruction based on the caller. br x16 or br x17 is compatible with both j and c instructions.

Based on the above comment, and original commit message (rGdbb95048da3a) this is stronger than is needed by this function. It might be better to create a new cache function for kexec.

Of course. ECAFFEINE (and going by uncaffeinated memory..)

Can you elaborate? This function is supposed to guarantee that the data is flushed out to memory before it returns; my reading of cpu_dcache_wb_range() is that it does this very thing.

To synchronise the D and I caches on arm64 the most we need to do is write back to the point of unification. cpu_dcache_wb_range will write back to the point of coherency which I expect to be further from the CPU.

If CTR_EL0.IDC is set then no D-cache operation is needed to make the I-cache coherent so nothing would be needed here.

Thinking on this, the name cpu_flush_cache() implies that once the function is complete the contents of the cache are flushed out to main memory, while pmap_sync_icache() implies that its purpose is to synchronize the D and I caches,. So just from the name cpu_flush_cache() provides a stronger guarantee of state at return.

*cpu_flush_dcache() of course...