mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2026-07-02 11:32:37 +00:00
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>