The psci_svc_cpu_data member of cpu_data must be accessed from early
entrypoint code, where the MMU/caching are off, as well as the normal
runtime, where the MMU/caching are on. As a result its accesses cannot
be guaranteed to be coherent and so we must issue CMOs ourselves.
Unfortunately, all CMOs operate on whole cache lines rather than
arbitrarily sized chunks of memory. So all of our CMOs with a size of
sizeof(psci_svc_cpu_data) get rounded up to the nearest cache line.
Since struct psci_cpu_data is declared as aligned to a cache line this
means that whatever lies on the latter parts of its cache line will get
affected too.
Up until the per-cpu framework, this was seemingly fine -
psci_svc_cpu_data was at the end of the cpu_data structure on most
configurations (as PAuth and EL3 exception handling are rarely enabled)
and due to it being a cache line aligned array it would be guaranteed to
sit on a cache line by itself. On configurations where it wasn't last,
it either wasn't a problem due to the access patterns of the other
members or they weren't in cache at the time of the CMOs.
Since the per-cpu framework the above is no longer true. The cpu_data
structure is no longer an array but rather an ordinary member of the
per-cpu region and since we do not enforce any ordering, anything could
be placed after it. When that happens the CMOs have a high chance of
affecting live data and usually leading to a crash.
This patch fixes the problem by asserting that struct psci_cpu_data will
sit alone on a cache line and the CMOs that we do will not have any
unexpected side effects.
The psci_cpu_data_t type alias is also removed to reduce ambiguity and
have a definitive type name for this.
Change-Id: I05cd5f720fea818fcd12fd47422be3e778aa7316
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
ad6e3f8aea