Re: [Xen-devel] [PATCH v4 2/2] arm: prefer PSCI for SMP bringup

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> 
> > On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> > > This way the 
> > > priority order would be:
> > > 
> > > - If mdesc->smp_init is non null then use that.
> > > 
> > > - Otherwise, if PSCI is available then use that.
> > > 
> > > - Otherwise use mdesc->smp.
> > > 
> > > This way, if the PSCI default has to be overriden (like in the MCPM case 
> > > because it needs to wrap PSCI itself, or to cover Rob's concern) then 
> > > this can be achieved at run time on a per mdesc basis.
> > 
> > Actually that's not a bad idea, it could make everybody happy.
> > What about the following, in this precise order:
> > 
> > - if a xen hypervisor node is present on device tree, use PSCI;
> > - otherwise if mdesc->smp_init is non null then use it;
> > - otherwise if PSCI is available then use it;
> > - otherwise use mdesc->smp.
> > 
> > It's the most practical solution to satisfy everybody's needs.
> 
> Regardless of my previous email suggesting a mdesc for xen, I still 
> don't understand why you need this absolute priority for Xen.  Isn't my 
> original suggestion sufficient?
> 
> The likely reason why mdesc->smp_init might be needed is to provide an 
> extra encapsulation layer before actually using PSCI instead of using it 
> directly.  Why would you need to bypass that?

Uhm.. maybe I wouldn't, I am not 100% sure TBH.

I am expecting that this "extra encapsulation layer" would read/write
some platform specific registers that Xen doesn't export.
If this is the case, then we would need to bypass it.

But if it's just to mangle parameters, then it should be OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel