linux-kernel - Re: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Apr 2013 14:20:44 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
cc:	Rob Herring <robherring2@...il.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	"marc.zyngier@....com" <marc.zyngier@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup

On Mon, 1 Apr 2013, Stefano Stabellini wrote:

> On Fri, 29 Mar 2013, Rob Herring wrote:
> > On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> > > On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > 
> > >> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> > >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > >>>
> > >>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
> > >>>> This is required for SMP support in Dom0 on Xen.
> > >>>>
> > >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@...citrix.com>
> > >>>> CC: will.deacon@....com
> > >>>> CC: arnd@...db.de
> > >>>> CC: marc.zyngier@....com
> > >>>> CC: linux@....linux.org.uk
> > >>>> CC: nico@...aro.org
> > >>>
> > >>> I'd suggest you also include in your series the patch I posted earlier 
> > >>> providing a runtime mdesc->smp_init method as well.
> > >>
> > >> OK.
> > >>
> > >>
> > >>> 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.
> > > 
> > > Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> > > of its own?  Given it is going to tweak the DT passed to the kernel 
> > > anyway that shouldn't be a problem.
> > 
> > Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
> > only for DomU guests. For Dom0, you still need all the platform specific
> > code except smp_ops. However, I'm doubtful this would work without other
> > changes on more complicated platforms like OMAP.
> > 
> > I would say wait to add this until you have platforms that actually need
> > the first case.
> 
> OK, that is not unreasonable.
> 
> 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.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/