On 19/06/2023 19:01, Julien Grall wrote:
>
>
> From: Julien Grall <jgr...@amazon.com>
>
> On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
> the following paragraph:
>
> "DMB and DSB instructions affect reads and writes to the memory system
> generated by Load/Store instructions and data or unified cache
> maintenance instructions being executed by the PE. Instruction fetches
> or accesses caused by a hardware translation table access are not
> explicit accesses."
>
> Newer revision (e.g. ARM DDI 0487J.a) doesn't have the second sentence
> (it might be somewhere else in the Arm Arm). But the interpretation is
> not much different.
>
> In setup_fixmap(), we write the fixmap area and may be used soon after,
> for instance, to write to the UART. IOW, there could be hardware
> translation table access. So we need to ensure the 'dsb' has completed
> before continuing. Therefore add an 'isb'.
>
> Fixes: 2b11c3646105 ("xen/arm64: head: Remove 1:1 mapping as soon as it is
> not used")
> Signed-off-by: Julien Grall <jgr...@amazon.com>
Reviewed-by: Michal Orzel <michal.or...@amd.com>
I'm happy with the whole series but I do not see a point in flooding each patch
with my tag
since you already got two (from Henry and Luca).
When it comes to essential isb() after dsb() in arm64 head.S, I can see that we
are missing one in enable_mmu()
after TLB invalidation. On HW without FEAT_ETS the TLB is "guaranteed to be
complete after the execution of
DSB by that PE, followed by a Context synchronization event", so I view isb as
necessary there. We could also
introduce (just like for arm32) flush_xen_tlb_local macro and use it there +
remove opencoding it.
~Michal