[LinuxBIOS] APICID lifting

[Eric W. Biederman]

San Mehat <san at google.com> writes:

> Nice stuff.. what happened to get_apicid_base()? :)
>
> linuxbios_ram.o(.text+0x7909): In function `smp_write_config_table':
> : undefined reference to `get_apicid_base'

An evolving understanding of what needs to happen.

We first replaced it in our tree with a function called max_lapicid()
that worked by looking at the device tree to see which apicid's had
already been used by the cpus.

For small cpu counts and small numbers of ioapics that worked well.

Then along came the observation that in all legacy apics and ioapics
only id's 0-15 are valid.  Currently most ioapics still have this
limitation where the cpus can be assigned id's 0-255.

Currently this is a problem for boards like the island/aruma which
have 14 io_apics and 4 cpus, or boards with 8 processor sockets
which can hold dual-core cpus.

So it was realized that for a general purpose solution the cpus apicid
must always be lifted.  So we made the formula for the cpus apicid
0x10 + coreid*0x10 + nodeid.  Which works consistently and should work
for everyone.  Unless someone has a buggy kernel which can't cope.

With all of the apicid's of the cpus above 16 max_lapicid() was
redundant and actually strongly incorrect for using to compute the
apicid_base, which we needed to place below 15.  So we dropped
the patch that fixed up all of the references to get_apicid_base,
to max_lapicid instead.

It just became apparent that we needed to either not kill
get_apicid_base or to have fixed up all of the references to
apicid_base with something else.

The simple correct solution is to just hardcode apicid_base to 1,
for the boards that use it.

The clean solution and probably what we want long term is a function
that places the ioapics in the device tree and assigns them the lowest
free ioapicid.  That code could probably move out of the mother board
files into the chipset specific code.  One more step along the lines
of clean interrupt handling.

Eric