good,

In the get_apicid_base,  i already make it use the hole for io apic under dual core and apic lifting even BSP is not lifted.

YH

On 10/8/05, Eric W. Biederman <ebiederman@lnxi.com> wrote:
Stefan Reinauer <stepan@openbios.org> writes:

> * Eric W. Biederman <ebiederman@lnxi.com> [050907 17:39]:
>> yhlu < yinghailu@gmail.com> writes:
>>
>> > at such case We need to enable 8 bit ext apic id mode for Opteron. So
> Opteron
>> > could use 0x10 above.
>> > and leave 0-0x0f to the device that can not support 8 bit apic id.
>> >
>> > I'm considering to align apic id lifting to the way that Norma BIOS does.
>>
>> Are io-apics limited to apic ids 0x0-0x0f as well?
>>
>> My memory says to me the limit should be 0x0-0xff...
>
> That's device specific I think. At least the 8131 has a maximum ioapic
> address of 0x0f. See the island/aruma board. It has 7 8131, an 8111 and
> 4 cpus. No way of getting this to work with Linux with LAPICs below
> 0x10.
>
> How can we get this running with the LNXI patch?

So I did a little bit of research and the original apics all only
support 0x0-0x0f  with 0x0f being the broadcast address.  So
since it appears we can only be able to count on the cpus having
large apicid support things need to be tweaked a little bit.

What that probably means is tweaking the default cpu apicid assignment
scheme, and tweaking the io-apicid address code to find holes in
the device tree instead of just looking for the end.  Something
like the current policy with the improved LNXI mechanism.

I hate running out of address bits!

Eric