Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit

[James Cleverdon <jamesclv@us.ibm.com>]

On Thursday 12 December 2002 07:05 pm, Nakajima, Jun wrote:
> BTW, we are working on a xAPIC patch that supports more than 8 CPUs in a
> generic fashion (don't use hardcode OEM checking). We already tested it on
> two OEM systems with 16 CPUs.
> - It uses clustered mode. We don't want to use physical mode because it
> does not support lowest priority delivery mode.
> - We also check the version of the local APIC if it's xAPIC or not. It's
> possible that some other x86 architecture (other than P4P) uses xAPIC.
>
> Stay tuned.
>
> Jun

See my 2.5 summit patch for one that uses logical mode and lowest priority 
delivery.  I haven't submitted that for 2.4 because the physical patch has 
the most run time on it, both in Alan's tree and SuSE 8.0+.

The hardcoded OEM checking was necessary because the Summit I/O APICs were 
still using the older version number.  (The HW folks claim that Intel didn't 
specify the new number soon enough for them.)

I'm hesitant to key xAPIC vs. flat off the local APIC version number because 
it's possible to build a flat system out of P4 CPUs.  I/O APIC version 
numbers combined with the parallel vs. serial bit would be safer (except for 
the Summit problem above).  I've also tried checking all the CPU's physical 
APIC IDs to see if they use multiple APIC clusters.

> > -----Original Message-----
> > From: James Cleverdon [mailto:jamesclv@us.ibm.com]
> > Sent: Thursday, December 12, 2002 6:42 PM
> > To: Zwane Mwaikambo
> > Cc: Martin Bligh; John Stultz; Linux Kernel
> > Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
> >
> > On Thursday 12 December 2002 06:21 pm, Zwane Mwaikambo wrote:
> > > On Thu, 12 Dec 2002, James Cleverdon wrote:
> > > > On Thursday 12 December 2002 05:44 pm, Zwane Mwaikambo wrote:
> > > > > Hi,
> > > > > 	I've got an 32x SMP system which has an xAPIC but utilises
> >
> > flat
> >
> > > > > addressing. This patch is to rename what was formerly x86_summit to
> > > > > x86_xapic (just to avoid confusion) and then select mask depending
> >
> > on
> >
> > > > > that.
> > > > >
> > > > > Untested/uncompiled patch
> > > >
> > > > Hi Zwane,
> > > >
> > > > How can you have a 32-way SMP system with flat addressing?  There are
> > > > only 8 bits in the destination address field.  Even if you work
> > > > around that by assigning a set of CPUs to each dest addr bit, there
> > > > can only
> >
> > be
> >
> > > > 15 physical APIC IDs in flat mode.  To get to 32 you must switch into
> > > > clustered mode.
> > > >
> > > > Please tell me more.  I'm intrigued how this can be done.
> > >
> > > Hi James,
> > > 	with the xAPIC we can use the 8bit address space everywhere in
> > > physical destination mode. For example the ICR now has an 8bit space
> > > for destination.
> > >
> > > "Specifies the target processor or processors. This field is only used
> > > when the destination shorthand field is set to 00B. If the destination
> > > mode is set to physical, then bits 56 through 59 contain the APIC ID of
> > > the target processor for Pentium and P6 family processors and bits 56
> > > through 63 contain the APIC ID of the target processor the for Pentium
> > > 4 and Intel Xeon processors. If the destination mode is set to logical,
> >
> > the
> >
> > > interpretation of the 8-bit destination field depends on the settings
> > > of the DFR and LDR registers of the local APICs in all the processors
> > > in
> >
> > the
> >
> > > system (see Section 8.6.2.,  Determining IPI Destination )."
> > > 	- System Developer's Manual vol3 p291
> > >
> > > Regards,
> > > 	Zwane
> >
> > Sure you can physically address them, if you assign IDs using Intel's
> > official
> > xAPIC numbering scheme (which must be clustered for more than 7 CPUs).
> > But,
> > you still don't have enough destination address bits to go around.  In
> > flat
> > mode, the kernel assumes you have one bit per CPU and phys IDs will be <
> > 0xF.
> >
> > Bill tells me that you may be doing this for an emulator.  Why not
> > emulate clusered APIC mode, like the real hardware uses?
> >
> > I know the name x86_summit doesn't really fit.  The summit patch should
> > work
> > for any xAPIC box that uses the system bus for interrupt delivery and has
> > multiple APIC clusters.  Is that what you're working towards?
> >
> > --
> > James Cleverdon
> > IBM xSeries Linux Solutions
> > {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com


-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com