Andy, Thanks for your clarification. andy sang: > It's x86 APIC Scalability project. > > Wiki: > http://agares.central.sun.com/twiki/bin/view/Sandbox/X86APICScalability > > PTL: > http://projectlog.sfbay/ptl/dashboard.php?UniqueID=6342 > > Thanks, > Andy > > Edward Shu ??: > >> What is the APIX project? Any point for this? >> Wesley Shao: >> >>> Edward Shu wrote: >>> >>> >>>> See comments below. >>>> 4. Technical Description >>>> >>>> >>>>> 4.1. Introduction >>>>> >>>>> Pcitool is a low-level tool which provides a facility for getting and >>>>> setting interrupt routing information. It is first introduced by >>>>> PSARC/2005/232 and then made public by PSARC/2009/215. Currently on >>>>> x86 it refers to an interrupt by using the interrupt vector, which >>>>> isn't unique on a multi-CPU x86 system. >>>>> >>>>> On x86 platforms, the interrupt vectors are associated with the local >>>>> APIC (Advanced Programmable Interrupt Controller) which is a component >>>>> of CPU. So the number of total interrupt vectors in the system scales >>>>> with the number of CPUs present in the system. And an interrupt vector >>>>> number is only unique on the CPU which owns the vector, it isn't >>>>> global >>>>> unique in a system which has multiple CPUs. >>>>> >>>>> To uniquely identify an interrupt on x86, both interrupt vector number >>>>> and the CPU which owns this vector are needed. This project will >>>>> define >>>>> the necessary changes to pcitool to uniquely identify an interrupt on >>>>> x86, and also it will propose some output changes to be more user >>>>> friendly. >>>>> >>>>> >>>>> >>>> When I type "'::interrupts" command in mdb, the output give me a list of >>>> activating >>>> interrupts. It seems that the interrupt vector is uniquely identified. >>>> >>>> >>> They won't be after the APIX project, hence the proposal. >>> >>> Wes >>> >>> >>> >>>> Why can't >>>> we use the same vectors instead of adding owning CPU? Here is an output >>>> example >>>> from a X86 system. >>>> >>>> IRQ Vect IPL Bus Trg Type CPU Share APIC/INT# Driver Name(s) >>>> 4 0xb0 12 ISA Edg Fixed 3 1 0x0/0x4 asy#0 >>>> 9 0x81 9 PCI Lvl Fixed 1 1 0x0/0x9 acpi_wrapper_isr >>>> 14 0x41 5 ISA Edg Fixed 2 1 0x0/0xe ata#0 >>>> 20 0x82 9 PCI Lvl Fixed 3 1 0x0/0x14 ehci#0 >>>> 21 0x83 9 PCI Lvl Fixed 0 1 0x0/0x15 ohci#0 >>>> 22 0x60 6 PCI Lvl Fixed 1 1 0x0/0x16 nge#0 >>>> 44 0x61 6 PCI Lvl Fixed 1 1 0x3/0x14 nge#1 >>>> 56 0x62 6 PCI Lvl Fixed 2 1 0x2/0x0 e1000g#0 >>>> 57 0x63 6 PCI Lvl Fixed 3 1 0x2/0x1 e1000g#1 >>>> 58 0x40 5 PCI Lvl Fixed 2 1 0x2/0x2 mpt#0 >>>> 160 0xa0 0 Edg IPI all 0 - poke_cpu >>>> 208 0xd0 14 Edg IPI all 1 - kcpc_hw_overflow_intr >>>> 209 0xd1 14 Edg IPI all 1 - cbe_fire >>>> 210 0xd3 14 Edg IPI all 1 - cbe_fire >>>> 240 0xe0 15 Edg IPI all 1 - xc_serv >>>> 241 0xe1 15 Edg IPI all 1 - apic_error_intr >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> -- >> Best Regards, >> Ming. >> >> ------------------------------------------ >> -Edward Shu >> -Solaris x86 Engineering, Sun Microsystems >> -tele: +86-10-62673100 >> __________________________________________ >> >> >> > >
-- Best Regards, Ming. ------------------------------------------ -Edward Shu -Solaris x86 Engineering, Sun Microsystems -tele: +86-10-62673100 __________________________________________
