On Mon, 22 Apr 2013, Russell King - ARM Linux wrote: > > > Now, if the psci stuff can't be relied upon to provide the correct > > > functionality, then that's a separate problem which needs addressing > > > differently. > > > > > > This should allow the Xen problem to be resolved, because Xen will > > > provide the PSCI operations, and it's correct in that case to override > > > the platform's SMP operations. > > > > Yes, increasing the priority of PSCI helps Xen a lot. > > In order to completely solve the issue for Xen though, another patch is > > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because > > of the introduction of smp_init. > > Given the way the code in setup.c will work: > > +static bool __init xen_smp_init(void) > +{ > +#ifdef CONFIG_SMP > + /* If we are running on Xen, use PSCI if available. > + * In any case do not try to use the native smp_ops. */ > + if (psci_smp_available()) > + smp_set_ops(&psci_smp_ops); > +#endif > + return true; > +} > > Doesn't this just need to return false, and then we'll drop down to > using PSCI if those operations are available?
If we are running on Xen, we are sure that the only available mechanism to boot secondary cpus is PSCI; there is no need to try anything else if that one is not available. This is way xen_smp_init is returning true unconditionally. However I am going to drop the "xen/arm: introduce xen_early_init, use PSCI on xen" patch linked above entirely, because I'll just assume that if we are running on Xen smp_init is going to fail and return false. The next option on the list is PSCI so in theory we won't have to do anything special to make it work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
