Hi
I think there are a few points being missed in this discussion: 1. If you want to implement a product that supports secure and non-secure world, and optionally virtualisation, you are always going to need something like PSCI. You can work around it and implement something else (e.g. MCPM) but you'd essentially be fixing the same problem in new ways, IOW replicating work. 2. When you go to ARMv8 you have to write secure world FW anyway. You can't just reuse what existed in ARMv7. EL3 needs to run in AArch64, and in addition it is a whole execution environment, it's not just a processor mode.
Additional comments below
Cheers
Charles
-----Original Message----- From: Catalin Marinas [mailto:catalin.marinas@arm.com] Sent: 02 September 2013 09:17 To: Nicolas Pitre Cc: Amit Kucheria; Leo Yan; Charles Garcia-Tobin; linaro- kernel@lists.linaro.org; Zhou Zhu; Chao Xie; Yu Tang; Neil Zhang; Mingliang Hu; Mark Hambleton; Christian Daudt Subject: Re: [Question] MCPM Supporting For ARM64
Hi Nico,
On Sat, Aug 31, 2013 at 03:19:46AM +0100, Nicolas Pitre wrote:
On Fri, 30 Aug 2013, Catalin Marinas wrote:
My position for the arm64 kernel support is to use the PSCI and implement the cluster power synchronisation in the firmware. IOW, no MCPM in the arm64 kernel :(. To help with this, ARM is going to provide a generic firmware implementation that SoC vendors can expand for their needs.
I am open for discussing a common API that could be shared between MCPM-based code and the PSCI one. But I'm definitely not opting for a light-weight PSCI back-end to a heavy-weight MCPM implementation.
Also note that IKS won't be supported on arm64.
I find the above statements a bit rigid.
While I think the reasoning behind PSCI is sound, I suspect some people will elect not to add it to their system. Either because the hardware doesn't support all the necessary priviledge levels, or simply because they prefer the easiest solution in terms of maintenance and upgradability which means making the kernel in charge. And that may imply MCPM. I know that ARM would like to see PSCI be adopted everywhere but I doubt it'll be easy.
I agree PSCI is not always possible because of technical reasons (missing certain exception levels), so let me refine the above statement: if EL3 mode is available on a CPU implementation, PSCI must be supported (which I think is the case for Marvell).
Also worth pointing out that PSCI works just as happily at the EL1<->EL2 boundary. It's a an easily virtualisable interface.
It indeed sounds rigid but what's the point of trying to standardise something if you don't enforce it? People usually try to find the easiest path for them which may not necessarily be the cleanest longer term. As a past example, how many SoC maintainers were willing to convert their code to DT if there wasn't a clear statement from arm-soc guys mandating this?
I think to be honest most of the commentary is derived from the fact that all of this is a "change". Nobody likes change, and there is some pain involved. But the point is that ARMv8 mandates change anyway. Doing it this way will lead to more standard methodologies and less change in the future. Compare this to what we have today in ARMv7 where everybody does their own thing.
In other words, if someone does the work to port MCPM to ARM64 and properly abstract the common parts with ARM32 then I don't see why you should refuse merging it.
I don't have a problem with the MCPM itself. It is nicely written and can probably be abstracted into a library. My concern is how MCPM is going to be used by the SoC code. The example I have so far is dcscb.c and I really want such code moved out of the kernel into firmware (or even better if there is some hardware control available). It is highly dependent to the SoC and CPU implementation and setting/clearing bits like ACTLT.SMP which is not possible in non-secure mode. I'm pretty sure that such code will end up doing non-standard SMC calls to the secure firmware and we lose any hope of standardisation.
The PSCI API can evolve in time (it has version information) but so far there is no such thing as "lightweight" PSCI that could be used as an MCPM back-end. For example, MCPM provides callbacks into the platform code when a CPU goes down to disable coherency, flush caches etc. and this code must call back into the MCPM to complete the CPU tear-down. If you want such thing, you need a different PSCI specification.
If you could work round that, MCPM on an PSCI implementation would effectively be a nop layer that does nothing but to forward calls onto PSCI. I don't see great value in that.
-- Catalin
-- 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