public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: Zwane Mwaikambo <zwane@holomorphy.com>
Cc: Martin Bligh <mbligh@us.ibm.com>,
	John Stultz <johnstul@us.ibm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
Date: Thu, 12 Dec 2002 18:41:32 -0800	[thread overview]
Message-ID: <200212121841.32381.jamesclv@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.50.0212122116260.6931-100000@montezuma.mastecende.com>

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


  reply	other threads:[~2002-12-13  2:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-13  1:44 [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit Zwane Mwaikambo
2002-12-13  2:09 ` James Cleverdon
2002-12-13  2:21   ` Zwane Mwaikambo
2002-12-13  2:41     ` James Cleverdon [this message]
2002-12-13  3:11       ` Zwane Mwaikambo
  -- strict thread matches above, loose matches on Subject: below --
2002-12-13  3:05 Nakajima, Jun
2002-12-13  3:21 ` James Cleverdon
2002-12-13  3:26 ` Zwane Mwaikambo
2002-12-13  3:32   ` James Cleverdon
2002-12-13  5:53     ` Steffen Persvold
2002-12-13 19:32       ` James Cleverdon
2002-12-13  3:20 Nakajima, Jun
2002-12-13 15:43 Nakajima, Jun
2002-12-13 19:40 ` James Cleverdon
2002-12-13 20:41 Nakajima, Jun
2002-12-17  2:30 Nakajima, Jun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200212121841.32381.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@us.ibm.com \
    --cc=zwane@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox