[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |