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:	Tue, 9 Apr 2013 13:21:45 +0100
From:	Dave Martin <dave.martin@...aro.org>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.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 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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ