On Mon, Sep 09, 2013 at 07:02:50PM +0100, Nicolas Pitre wrote:
On Mon, 9 Sep 2013, Lorenzo Pieralisi wrote:
On Mon, Sep 09, 2013 at 02:02:47PM +0100, Catalin Marinas wrote:
Taking the TC2 code example (it may be extended, I don't know the plans here) it seems that the cpuidle driver is only concerned with the C1 state (CPU rather than cluster suspend). IIUC, cpuidle is not aware of deeper sleep states. The MCPM back-end would get an expected residency information and make another decision for deeper sleep states. Where does it get the residency information from? Isn't this the estimation done by the cpuidle governor? At this point you pretty much move part of cpuidle governor functionality (and its concepts like target residency) down to the MCPM back-end level. Such split will have bad consequences longer term with code duplication between back-ends, harder to understand and maintain cpuidle decision points.
IMHO the subject of this thread should not be related to power management policy decisions and where they should live. The goal of MCPM and PSCI was not about defining policy for power management but providing mechanism and I agree with Catalin on this, we have to keep them separate.
I do agree as well. That's not where my argument fundamentally is. Please let's not divert the discussion again.
To avoid diverting the discussion, we first need to agree on what this discussion is about. As Lorenzo said, the goal of MCPM or PSCI was not about defining policy but coordinating the C states in a multi-cluster context (with or without security implications). Policy in MCPM is a new thing you brought and if that's the future plan I want to stay far away from it. Selling MCPM as the next idle governor does not work for me, sorry.
Going back to the original topic, when we talk about MCPM vs PSCI in the arm64 context, we need to be clear on _which_ parts of MCPM to consider. PSCI is clearly defined, MCPM is not (as you said, it's work in progress but you can probably set high-level goals). So let's start with defining MCPM and please correct my understanding (based on what's currently in mainline):
1. Front-end to CPU hotplug and cpuidle. 2. Common back-end interface to low-level SoC power management. I would add mcpm_entry_vectors setting here. 3. 'last man' state machine for CPU/cluster power coordination.
I hope it is clear by now that if you care about _proper_ security in the power management context, point 3 above must be handled in firmware. That's independent of how complex the firmware needs to be for such task. PSCI as an API and the Generic Firmware implementation is addressing this (and at the same time providing a common framework for secure OS vendors to rely on). Generic Firmware will be further developed to address other concerns but that's not the point. Myself and others in this thread stated the security requirements for such complexity in firmware several times already. You can complain about the ARM secure architecture but, again, that's not something to be addressed in this thread.
So, if PSCI is needed in firmware for security reasons, it already takes care of point 3 above and it pretty much eliminates the need for 2 (if 2 is still needed, usually something is wrong in the SoC security model since non-secure OS should not be allowed power management actions that affect the secure layer coherency). We are left with point 1 which currently is smp_ops, so not a new interface for MCPM. PSCI support on arm64 plugs into smp_ops directly, so I don't see a need for MCPM front-end plus PSCI as back-end, it's just a no-op level of indirection.
I do _agree_ that not all SoCs have (TrustZone-like) security needs. There are two classes here: (a) EL3 is not present and (b) vendors don't plan to support a secure layer.
For (a) things are pretty clear, they need a 'last man' state machine for power management in the (only, no secure/non-secure differentiation) OS and this can be addressed by existing implementations like MCPM (point 3). As I said in a previous email, I would rather use MCPM as a library driven from SoC power management code, possibly overriding cpu_operations (currently smp_ops or a new class of cpu_pm_ops) with mcpm_* ones. Implementation details TBD (as needed) but an important aspect here is that MCPM or PSCI are _interchangeable_ and there won't be an MCPM framework with PSCI as back-end (see above on why I don't see value here).
Class (b) - EL3 present but no (apparent) need for a secure layer - is what I think this thread should be about. Here you have SoC vendors that simply don't need a security layer and others that don't bother (because it's the final mobile device manufacturer that has to put up with the secure OS integration). But they all need to deal with some level of firmware at EL3 because (1) that's the mode the CPU starts at and (2) that's where it needs to go to back for certain actions like ACTLR.SMP bit. These SMC calls I would really like standardised and PSCI is one way of doing it (MCPM doesn't really care about the firmware interface, that's a back-end issue). The TC2 MCPM implementation is not a good example for this case because it runs in secure mode and it's not an ARMv8/AArch64 SoC either.
My question (ignoring the security holes): if you _need_ EL3 to handle coherency enabling/disabling (ACTLR.SMP, CCI etc. not available at non-secure EL1), can you avoid a 'last man' state machine in the firmware and just rely on a non-secure EL1 (MCPM) state machine?
And please don't bring back the argument that Linux is more flexible, easily upgradable than the firmware, I don't dispute these. That's not a better code contest but a real technical problem regarding the interaction between non-secure OS and secure firmware. As far as I'm aware, the majority of (in development) ARMv8 implementations have EL3.
Hopefully I got the discussion back on track.