RE: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16

[Lu, Yinghai]

I didn't catch you.

For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be
used by ioapic.

YH

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, September 06, 2005 1:13 PM
To: yhlu
Cc: [e-mail]
Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16

yhlu  writes:
> use max_lapicid() + 1 as apicid_base is not good.
>
> esp for apic id lifting.
>
> for 8 way dual core system, max_lapicid() will be 0x0f with lifting,

and with
> lifting it will be 0x1f.

The x86 standard is now is tuples of (nodeid, coreid) which
means on k8 based systems the cpu apicids will always be densly
packed.  I haven't seen the reference but I have been assured that
is the way things are working.  I believe it was Richard Breuner assured
me of this

In addition in the code cleanups that have been us only use the (nodeid,
coreid)
as supporting multiple form simultaneously is both confusing, and
creates
code that is hard to maintain.

Eric

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

"Lu, Yinghai"  writes:
> I didn't catch you.
>
> For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be
> used by ioapic.

With the set of changes apicids will be 0x0-0x0f with 8way dual cores.
If that is not sensible we can change the generic code as all of
the apicid assignment is now in generic code.

Eric

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

[yhlu]

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.

YH

On 9/6/05, Eric W. Biederman  wrote:
> "Lu, Yinghai"  writes:
> > I didn't catch you.
> >
> > For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be
> > used by ioapic.
>
> With the set of changes apicids will be 0x0-0x0f with 8way dual cores.
> If that is not sensible we can change the generic code as all of
> the apicid assignment is now in generic code.
>
> Eric

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

yhlu  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...

Eric

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

[Stefan Reinauer]

* Eric W. Biederman  [050907 17:39]:
> yhlu  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?

Stefan.

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

Stefan Reinauer  writes:
> Eric W. Biederman  [050907 17:39]:
> > yhlu  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

[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

[yhlu]

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  wrote:
> Stefan Reinauer  writes:
> > Eric W. Biederman  [050907 17:39]:
> > > yhlu  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