On Tue, Sep 09, 2014 at 11:22:56AM +0100, Mark Rutland wrote:
> On Tue, Sep 09, 2014 at 04:55:56AM +0100, Jon Masters wrote:
> > Hi Hanjun, Lorenzo,
> >
> > On 09/04/2014 11:29 AM, Hanjun Guo wrote:
> >
> > > Hi Lorenzo,
> >
> > >>> + } else {
> > >>> + /* Fist GICC entry must be BSP as ACPI spec said */
> > >> s/Fist/First/
> > >>
> > >>> + if (cpu_logical_map(0) != mpidr) {
> > >>> + pr_err("First GICC entry is not BSP for MPIDR 0x%llx\n",
> > >>> + mpidr);
> > >>> + return -EINVAL;
> > >>> + }
> > >> Interesting, this means that if I want to change the boot CPU I have to
> > >> recompile the ACPI tables. Is that really true ?
> >
> > Well, the ACPI5.1 specification does require that the PEs (cores) be
> > listed in a very specific order, with the boot CPU first, and then a
> > precisely defined sequence of interleaving of any possible SMT threads
> > with other cores. So I think you would in practice update your tables.
>
> That'll be fun if we ever want to do a kexec from a CPU other than the
> BSP (where logical CPU0 may be arbitrary), but perhaps that's
> inadvisable for other reasons?
>
> Regardless, we should make a lot of noise if the spec says one thing and
> the platform does another. Is there any other way of distinguishing the
> BSP from the APs?
>
The x86 guys already found this and there is a work around in the
kernel. One of the patches that was acepted for 3.17 was my fix for the
workaround to make it not x86 specific.
Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
