On 13-09-03 11:11 AM, Dave Martin wrote:
On Tue, Sep 03, 2013 at 05:28:29PM +0100, Catalin Marinas wrote:
OK, let me clarify. I took the dcscb.c example for CPU going down (please correct me if I got it wrong):
You do miss a couple of things here:
mcpm_cpu_power_down() dcscb_power_down()
__mcpm_cpu_going_down(cpu, cluster);
flush_cache_all() - both secure and non-secure set_auxcr() - secure-only
last_man && __mcpm_outbound_enter_critical(cpu, cluster);
cci_disable_port_by_cpu() - secure-only? (__mcpm_outbound_leave_critical()) __mcpm_cpu_down() wfi()
In other words, the whole state machine is driven from the backend. The __mcpm_*() helpers are library functionality to help you manage it, but if your backend has its own methods of doing the coordination (as with the proposed PSCI-based backend) then there'so no compulsion to use them at all. There is no transfer of control away from the backend at eny point.
This is all about providing people who need to write a native Linux backend with tools for doing so.
Of course, the only purpose of MCPM in that scenario is to allow allow both kinds of backend to present a common interface to the kernel. This is only needed if both kinds of backend exist together, and the arch's smp_ops (or equivalent) provides an insufficient abstraction (I'm not familiar yet with how things look on arm64).
So the dcscb back-end calls back into MCPM to update the state machine. If you are to run Linux in non-secure mode, set_auxcr() and CCI would need secure access. Cache flushing also needs to affect the secure cachelines and disable the caches on the secure side. So from the flush_cache_all() point, you need to get into EL3. But MCPM requires (as I see in the dcscb back-end) a return from such EL3 code to call __mcpm_cpu_down() and do WFI on the non-secure side. This is incompatible with the (current) PSCI specification.
So in the PSCI case, most of these backend methods would simply translate to calls into PSCI (with some argument and semantics kludging to align the two interfaces).
From a personal point of view I would like to see wider use of MCPM, but ... it really comes down to how many native backends we get. If the way the TZ architecture works blocks native backends from existing on most platforms, we might see none or almost none, though.
I completely agree. I think that the the mcpm-on-psci scenario is (a) useful and (b) simple and (b) works on an already established kernel framework, so I see no reason to try to replace mcpm with psci for armv8, short or long term. It will be much better to have this flexibility built in, even if in most cases it is not utilized. There will be cases where it will be utilized. And while it is nice to wish that platform vendors all provide upgradeable EL3 implementations, the plain truth is that we are far away from that at this point, having barely (and not fully) arrived there @ kernel+userspace at present for the mobile space... To count on that as the basis for dismissing the need for mcpm as a flexible injection point is just asking for headaches. If it becomes true in the future that mcpm becomes an unecessary shim to psci for all platforms, then it will be easy enough to drop it out of the picture at that time. I suspect it will not.
Thanks, csd