[PATCH v4 2/2] arm: prefer PSCI for SMP bringup

[dave.martin@linaro.org (Dave Martin)]

On Tue, Apr 02, 2013 at 12:11:25PM -0400, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> > > On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> > > > What are the platforms that are going to use smp_init? Do we know how do
> > > > they intend to use it?
> > > 
> > > VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
> > > VExpress, the MCPM layer needs to arbitrate power management operations 
> > > on a per cluster basis.  In that case there is a MCPM specific set of 
> > > SMP ops to be used, even if it may end up calling into PSCI.
> > > 
> > > But the important point is that we don't know beforehand what to use, 
> > > especially with a kernel that can boot on multiple different VExpress 
> > > configurations.  The decision has to be made at run time, and therefore 
> > > a static default or mdesc->smp ops doesn't cut it.
> > 
> > I certainly like the principle and I am in favor of anything that moves
> > the decisions at runtime. I have pulled the patch in the series, it's
> > going to be in the next version.
> > 
> > However I am concerned that these platform specific operations won't
> > work with Xen at all.
> > I am getting increasingly certain that we need a Xen specific check in
> > setup_arch to bump up of the priority of PSCI over anything else if Xen
> > is running. 
> 
> I'm concerned about mixing big.LITTLE and Xen as well.  I don't think 
> this is going to make an easy match.  KVM might have an easier fit here.
> 
> But, in any case, even if the MCPM layer gets involved, if Xen is there 
> then PSCI will end up being the ultimate interface anyway.

Note that big.LITTLE != MCPM.  Virtualisation hosts might be large multi-
cluster systems, but the CPUs might be all of the same type.  MCPM or
similar would me needed for the multi-cluster power management even
though there is no big.LITTLE mix of CPUs.

> But let's cross that bridge when we get to it.  For now this is still a 
> non existing problem.

That's a big open question.  Either the host or hypervisor needs to be
very clever about scheduling guests, or you need to bind each guest virtual
CPU to a specific class of physical CPUs -- so, for example you provide
a guest with an explicit mix of bigs and littles.

All we can say about that for now is that it's a potential research area...

Cheers
---Dave