[snip]
I respect your opinion but do you have a more concrete proposal? The options so far:
(current status) Don't use PSCI firmware, let Linux handle all the CPU power management (possibly under the MCPM framework). If not all power-related actions can be done at the non-secure level, just implement non-standard SMC calls as needed. If these are changed (because in time vendor may have other security needs), add them to the driver and hope they have a way to detect or just not upstream the #ifdef'ed code.
New standard firmware interface, simpler and less error-prone. Handle most power management in Linux (with an MCPM-like state machine) and have guaranteed race-free calls to the firmware. In the process, also convince the secure OS guys that Linux is part of their trusted environment (I personally trust Linux more than the trusted OS ;) but this doesn't hold any water for certification purposes). Basically if you can disable coherency from the non-secure OS (e.g. CCI or just powering down a CPU without the secure OS having the chance to flush its caches), the only workaround for the secure OS would be to run UP (which is probably the case now) or flush caches at every return to the non-secure world.
Very similar to 2, with PSCI firmware interface but without the requirements to do cluster state coordination in firmware (with some semantic changes to the affinity arguments). Linux handles the state coordination (MCPM state machine) but PSCI firmware does the necessary flushing, coherency disabling based on the specified affinity level (it doesn't question that because it does not track the "last man"). Slightly better security model than 2 as it can flush the secure OS caches but I'm not entirely sure PSCI can avoid a state machine and whether this has other security implications.
MCPM state machine on top of full PSCI. Here I don't see the point of tracking cluster/last-man state in Linux if PSCI does it already. If PSCI got it wrong (broken coherency, deadlocks), MCPM cannot really solve it. Also, are there additional races by having two separate state machines for the same thing (I can't think of any now)?
Full PSCI with a light wrapper (smp_operations) allowing SoC to hook additional code (only if needed for parts which aren't handled by firmware). This is similar to the mcpm_platform_ops registration but *without* the MCPM state machine and without the separate cpu/cluster arguments (just linearise this space for flexibility). Other key point is that the re-entry address is driven via PSCI rather than mcpm_entry_vectors. Platform ops registration is optional, just available for flexibility (which could also mean that it is not the platform ops driving the final PSCI call, different from the MCPM framework). This approach does not enforce a secure model, it's up to the SoC vendor to allow/prevent non-secure access to power controller, CCI etc. But it still mandates common kernel entry/exit path via PSCI.
Full PSCI with generic CPU hotplug and cpuidle drivers. I won't list the pros/cons, that's what this thread is mainly about.
Any other options?
My goal is for 6 but 5 could be a more practical/flexible approach.
Both those options (5 and 6) imply the state machine is in the firmware. And that's where complexity lies. So that wouldn't be my choice at all.
Option 4 is rather useless. In fact the MCPM backend for PSCI I showed you doesn't exercise the MCPM state machine. And the firmware still implements a state machine.
Differences between 2,3,4 are a bit fuzzy to me. I understand the issue with having a secure OS that needs to protect itself from the nasty Linux world. However, if I understand the model right, the secure OS is there to provide special services to the non-secure OS and not the reverse. Therefore the secure OS should simply pack and hide its things when told to do so, right?
Of course option 1 is the most flexible in terms of implementation efficiency, but it has drawbacks as well.
As I said in a previous post, I'm not against MCPM as such but against the back-ends which will eventually get non-standard secure calls.
Maybe the secure call standardization should focus on providing less abstract and more low-level interfaces then. Right now, the PSCI definition implies that everything is performed behind the interface.
Sorry but you are late for this call. PSCI has been discussed for nearly two years and you have been involved.
And two years later I've gained enough experience to state that this might not be such a good idea for all cases after all. Sometimes you may not realize all the ramifications of a concept or design until you do actual work on it.
And this is not my call to make either. System vendors will choose their own poison for themselves. Between risk inducing complexity in secure firmware and non-standard low-level machine specific L3 calls I don't think there is much to rejoice about.
But my point is that there is legitimacy in both models and right now I don't see a single "true" solution. Hence my claim that you should not insist on PSCI or nothing.
My main problem is that I only see MCPM being legitimate in a system where linux runs in secure world. Here all the coherency/cache management, and by consequence last man tracking etc, can be done happily in Linux. However if you are going to productise a device, and consequently run linux non-secure then you need PSCI. As pointed out before in this thread, you can't disable coherency from linux or ignore secure cache maintenance. If you go with MCPM you end up in a situation where folk will do bring up using that, ignore sorting out their FW, and then end up either asking for obscure, very platform specific ways back doors into the secure world like we have today. This will obviate the whole point of PSCI, and the whole effort. If you go with PSCI you'd encourage a model where folk do it properly from the start. I can understand the need for flexibility, so having a system which ultimately always calls PSCI, but which allows a SoC callback in the path (which is essentially the option 5 above) makes sense to me. This model encourages adoption of PSCI, but gives the flexibility for early adoption and provides a development path. Finally I just don't think we should use the "FW has been crap in the past" card as way to discourage FW for ever more. That's not the right answer, there are valid uses for it and a whole industry around it. I absolutely agree with using the card to encourage better development of FW in the future. Standardised APIs is part of that story.
Charles
Nicolas
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782