From phitran@sac.sfbay.sun.com Mon Dec  7 14:28:23 2009
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7MSNiG004577
	for <psarc-ext@sac.sfbay.sun.com>; Mon, 7 Dec 2009 14:28:23 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7MSNEp029617;
	Mon, 7 Dec 2009 14:28:23 -0800 (PST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUA00705ZRBND00@brm-avmta-1.central.sun.com>; Mon,
 07 Dec 2009 15:28:23 -0700 (MST)
Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUA002NQZRARLB0@brm-avmta-1.central.sun.com>; Mon,
 07 Dec 2009 15:28:22 -0700 (MST)
Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4)
 with ESMTP id nB7MSLqH024061; Mon, 07 Dec 2009 14:28:21 -0800 (PST)
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7MSKgF004572; Mon,
 07 Dec 2009 14:28:20 -0800 (PST)
Received: (from phitran@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB7MSJI6004568; Mon,
 07 Dec 2009 14:28:19 -0800 (PST)
Date: Mon, 07 Dec 2009 14:28:19 -0800 (PST)
From: Phi Tran <phitran@sac.sfbay.sun.com>
Subject: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
To: PSARC-ext@sun.com
Cc: David.Chieu@sun.com, Zhijun.Fu@sun.com, apic-dev@sun.com
Message-id: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 6883

I'm sponsoring this case for Zhijun Robin Fu with a requested patch binding 
and volatile commitment.

Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 Pcitool Extensions
    1.2. Name of Document Author/Supplier:
	 Author:  Zhijun Fu
    1.3  Date of This Document:
	07 December, 2009

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.

4.2. Details

 - Pcitool syntax changes

    Current syntax:
    	pcitool pci@<unit-address> -i <ino#> | all
    	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
  
    	pcitool pci@<unit-address> -m <msi#> | all
    	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]

    Proposed syntax:
    	pcitool pci@<unit-address> -i <cpu#,ino#> | all
    	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
  
    	pcitool pci@<unit-address> -m <cpu#,msi#> | all
    	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]

    On SPARC platforms, use "-i" option to retrieve or reroute a given INO,
    and where as use "-m" option for MSI/Xs. On x86 platforms, use "-i" option
    to retrieve and reroute any interrupt vectors (both INO and MSI/Xs).
    "-m" option is not required on x86 platforms. Hence it is not supported.
 
    This project adds a new "cpu#" field in addition to "ino#" to uniquely
    represent an interrupt on x86 platform. The new field is not required
    for SPARC platforms, thus is ingored in these cases.

 - Pcitool output changes

   This project also makes some changes to simplify the pcitool output, making
   it more user friendly.

   Current output:

     Show ino 0x19 on /pci@1e,600000

       # pcitool /pci@1e,600000 -i 19

       ino 19 mapped to cpu 0
       Device: /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1
         Driver: mpt, instance 0
 
     Reroute ino 0x19 from cpu 0 to cpu 1 

       # pcitool /pci@1e,600000 -i 19 -w 1

       Interrupts on ino 19 reassigned: Old cpu: 0, New cpu: 1
 
     Reroute a group of INOs starting at 60 from cpu 0 to cpu 1

       # pcitool /pci@0,0 -i 60 -w 1 -g

       Interrupts on ino group starting at ino 60 reassigned: Old
       cpu: 0, New cpu: 1

   Proposed output:

     Show ino 0x19 on /pci@1e,600000

       # pcitool /pci@1e,600000 -i 19

       0x0,0x19: mpt0 /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1
 
     Reroute ino 0x19 from cpu 0 to cpu 1 

       # pcitool /pci@1e,600000 -i 19 -w 1

       0x0,0x19 -> 0x1,0x19
 
     Reroute a group of INOs starting at 60 from cpu 0 to cpu 1

       # pcitool /pci@0,0 -i 60 -w 1 -g

       0x0,0x60 => 0x1,0x60
   
   Note that on x86 platforms cpu must be specified along with ino, and the
   ino might change after being rerouted to another cpu. In this case reroute
   ino 0x19 from cpu 0 to cpu 1 could be:

       # pcitool /pci@1e,600000 -i 0,19 -w 1

       0x0,0x19 -> 0x1,0x21

     Show ino 0x19 on cpu 0:

       # pcitool /pci@1e,600000 -i 0,19

       0x0,0x19: mpt0 /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1

 
 - Data structure changes

   pcitool_intr_set_t

      This is the argument data structure for PCITOOL_DEVICE_SET_INTR ioctl,
      which maps a given interrupt or a group of interrupt to a given CPU.
      This project adds a new field "old_cpu" to identify the CPU which
      owns the interrupt vector, this together with interrupt vector number
      uniquely represents the interrupt to be rerouted.
      
   pcitool_intr_info_t

      This is the argument data structure for PCITOOL_SYSTEM_INTR_INFO ioctl,
      which retrieves system interrupt information. This project adds a new
      field "num_cpu" to reflect how many CPUs are present in the system,
      since the number of total interrupt vectors in the system scales with
      the number of CPUs.

4.3. Interfaces

   Imported Interfaces

    Interface			Stability	Comments
    ----------------------------+---------------+--------------------------
    pcitool                     Project	        Some syntax changes. Added
                                Private         new cpu# field, changed out-
                                                put format
    PCITOOL_DEVICE_SET_INTR     Consolidation   Ioctl to remap CPU of intr
                                Private	        or group of intr
    PCITOOL_SYSTEM_INTR_INFO    Consolidation   Ioctl to retrieve system 
                                Private         interrupt info
    pcitool_intr_set_t          Consolidation   PCITOOL_DEVICE_SET_INTR arg
                                Private         data structure
    pcitool_intr_info_t         Consolidation   PCITOOL_SYSTEM_INTR_INFO arg
                                Private         data structure 
    -----------------------------------------------------------------------


4.4. Dependencies

   The changes described in this case will be done as a follow on work to the
   following RFE:

   CR 6669984 Solaris x86 need to provide large number of interrupt vectors
	 for MSI/MSI-X

   The reason for this dependency is the inherent limitations on the current
   implementation of pcplusmp module (APIC module), where the total number
   of vectors available in the system is limited to only the number of vectors
   of a single APIC. So having these changes on the current implementation
   adds no value to the system.

   NOTE: The current plan is to integrate the pcitool changes along with
   the APIC code changes for the above RFE.


5. References
   [1]  PCITool and its nexus ioctl support - PSARC/2005/232
	http://sac.sfbay.sun.com/PSARC/2005/232

   [2]  PCITool Public Interrupts - PSARC/2009/215
	http://sac.sfbay.sun.com/PSARC/2009/215


6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open


From gdamore@sun.com Mon Dec  7 14:36:51 2009
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7MapOo004698
	for <psarc-ext@sac.sfbay.sun.com>; Mon, 7 Dec 2009 14:36:51 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7MaoIc003621;
	Mon, 7 Dec 2009 14:36:50 -0800 (PST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUB0080505EI400@brm-avmta-1.central.sun.com>; Mon,
 07 Dec 2009 15:36:50 -0700 (MST)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUB0024105DRLE0@brm-avmta-1.central.sun.com>; Mon,
 07 Dec 2009 15:36:50 -0700 (MST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7ManhN007750;
 Mon, 07 Dec 2009 14:36:49 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUB00J0001UNB00@fe-sfbay-10.sun.com>; Mon,
 07 Dec 2009 14:36:49 -0800 (PST)
Received: from [192.168.251.11] ([unknown] [76.93.15.33])
 by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUB00DPT05COJ20@fe-sfbay-10.sun.com>; Mon,
 07 Dec 2009 14:36:49 -0800 (PST)
Date: Mon, 07 Dec 2009 14:36:48 -0800
From: "Garrett D'Amore" <gdamore@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
Sender: Garrett.Damore@sun.com
To: Phi Tran <phitran@sac.sfbay.sun.com>
Cc: PSARC-ext@sun.com, David.Chieu@sun.com, Zhijun.Fu@sun.com,
        apic-dev@sun.com
Message-id: <4B1D8380.1010404@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20091013)
Status: RO
Content-Length: 7568

Personally, I find the new syntax and the new output a bit awkward -- 
anyone not intimately familiar with the tool is going to have trouble 
understanding what 0x1,0x8  means.

I think I'd rather keep the two separate in the output, and add a new 
switch (-p ?) for the "original" cpu id for x86 platforms.

    - Garrett

Phi Tran wrote:
> I'm sponsoring this case for Zhijun Robin Fu with a requested patch binding 
> and volatile commitment.
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
>     1.1. Project/Component Working Name:
> 	 Pcitool Extensions
>     1.2. Name of Document Author/Supplier:
> 	 Author:  Zhijun Fu
>     1.3  Date of This Document:
> 	07 December, 2009
>
> 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.
>
> 4.2. Details
>
>  - Pcitool syntax changes
>
>     Current syntax:
>     	pcitool pci@<unit-address> -i <ino#> | all
>     	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
>   
>     	pcitool pci@<unit-address> -m <msi#> | all
>     	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
>
>     Proposed syntax:
>     	pcitool pci@<unit-address> -i <cpu#,ino#> | all
>     	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
>   
>     	pcitool pci@<unit-address> -m <cpu#,msi#> | all
>     	[ -r [ -c ] | -w <cpu#> [ -g ] ] [ -v ] [ -q ]
>
>     On SPARC platforms, use "-i" option to retrieve or reroute a given INO,
>     and where as use "-m" option for MSI/Xs. On x86 platforms, use "-i" option
>     to retrieve and reroute any interrupt vectors (both INO and MSI/Xs).
>     "-m" option is not required on x86 platforms. Hence it is not supported.
>  
>     This project adds a new "cpu#" field in addition to "ino#" to uniquely
>     represent an interrupt on x86 platform. The new field is not required
>     for SPARC platforms, thus is ingored in these cases.
>
>  - Pcitool output changes
>
>    This project also makes some changes to simplify the pcitool output, making
>    it more user friendly.
>
>    Current output:
>
>      Show ino 0x19 on /pci@1e,600000
>
>        # pcitool /pci@1e,600000 -i 19
>
>        ino 19 mapped to cpu 0
>        Device: /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1
>          Driver: mpt, instance 0
>  
>      Reroute ino 0x19 from cpu 0 to cpu 1 
>
>        # pcitool /pci@1e,600000 -i 19 -w 1
>
>        Interrupts on ino 19 reassigned: Old cpu: 0, New cpu: 1
>  
>      Reroute a group of INOs starting at 60 from cpu 0 to cpu 1
>
>        # pcitool /pci@0,0 -i 60 -w 1 -g
>
>        Interrupts on ino group starting at ino 60 reassigned: Old
>        cpu: 0, New cpu: 1
>
>    Proposed output:
>
>      Show ino 0x19 on /pci@1e,600000
>
>        # pcitool /pci@1e,600000 -i 19
>
>        0x0,0x19: mpt0 /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1
>  
>      Reroute ino 0x19 from cpu 0 to cpu 1 
>
>        # pcitool /pci@1e,600000 -i 19 -w 1
>
>        0x0,0x19 -> 0x1,0x19
>  
>      Reroute a group of INOs starting at 60 from cpu 0 to cpu 1
>
>        # pcitool /pci@0,0 -i 60 -w 1 -g
>
>        0x0,0x60 => 0x1,0x60
>    
>    Note that on x86 platforms cpu must be specified along with ino, and the
>    ino might change after being rerouted to another cpu. In this case reroute
>    ino 0x19 from cpu 0 to cpu 1 could be:
>
>        # pcitool /pci@1e,600000 -i 0,19 -w 1
>
>        0x0,0x19 -> 0x1,0x21
>
>      Show ino 0x19 on cpu 0:
>
>        # pcitool /pci@1e,600000 -i 0,19
>
>        0x0,0x19: mpt0 /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1
>
>  
>  - Data structure changes
>
>    pcitool_intr_set_t
>
>       This is the argument data structure for PCITOOL_DEVICE_SET_INTR ioctl,
>       which maps a given interrupt or a group of interrupt to a given CPU.
>       This project adds a new field "old_cpu" to identify the CPU which
>       owns the interrupt vector, this together with interrupt vector number
>       uniquely represents the interrupt to be rerouted.
>       
>    pcitool_intr_info_t
>
>       This is the argument data structure for PCITOOL_SYSTEM_INTR_INFO ioctl,
>       which retrieves system interrupt information. This project adds a new
>       field "num_cpu" to reflect how many CPUs are present in the system,
>       since the number of total interrupt vectors in the system scales with
>       the number of CPUs.
>
> 4.3. Interfaces
>
>    Imported Interfaces
>
>     Interface			Stability	Comments
>     ----------------------------+---------------+--------------------------
>     pcitool                     Project	        Some syntax changes. Added
>                                 Private         new cpu# field, changed out-
>                                                 put format
>     PCITOOL_DEVICE_SET_INTR     Consolidation   Ioctl to remap CPU of intr
>                                 Private	        or group of intr
>     PCITOOL_SYSTEM_INTR_INFO    Consolidation   Ioctl to retrieve system 
>                                 Private         interrupt info
>     pcitool_intr_set_t          Consolidation   PCITOOL_DEVICE_SET_INTR arg
>                                 Private         data structure
>     pcitool_intr_info_t         Consolidation   PCITOOL_SYSTEM_INTR_INFO arg
>                                 Private         data structure 
>     -----------------------------------------------------------------------
>
>
> 4.4. Dependencies
>
>    The changes described in this case will be done as a follow on work to the
>    following RFE:
>
>    CR 6669984 Solaris x86 need to provide large number of interrupt vectors
> 	 for MSI/MSI-X
>
>    The reason for this dependency is the inherent limitations on the current
>    implementation of pcplusmp module (APIC module), where the total number
>    of vectors available in the system is limited to only the number of vectors
>    of a single APIC. So having these changes on the current implementation
>    adds no value to the system.
>
>    NOTE: The current plan is to integrate the pcitool changes along with
>    the APIC code changes for the above RFE.
>
>
> 5. References
>    [1]  PCITool and its nexus ioctl support - PSARC/2005/232
> 	http://sac.sfbay.sun.com/PSARC/2005/232
>
>    [2]  PCITool Public Interrupts - PSARC/2009/215
> 	http://sac.sfbay.sun.com/PSARC/2009/215
>
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>    	6.4.1. Consolidation C-team Name:
> 		ON
>     6.5. ARC review type: FastTrack
>     6.6. ARC Exposure: open
>
>   


From Edward.Shu@Sun.COM Tue Dec  8 17:58:28 2009
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB91wS1o026287
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 17:58:28 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB91wSSV017630;
	Tue, 8 Dec 2009 17:58:28 -0800 (PST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD00F0145GN800@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 17:58:28 -0800 (PST)
Received: from sineb-mail-1.sun.com ([192.18.19.6])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD001KZ45FQCE0@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 17:58:28 -0800 (PST)
Received: from fe-apac-05.sun.com
 (fe-apac-05.sun.com [192.18.19.176] (may be forged))
	by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB91wQLl014382; Wed,
 09 Dec 2009 01:58:26 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00G003ZETP00@mail-apac.sun.com>; Wed, 09 Dec 2009 09:58:26 +0800 (SGT)
Received: from [129.158.218.35] ([unknown] [129.158.218.35])
 by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD008R545DOX40@mail-apac.sun.com>; Wed,
 09 Dec 2009 09:58:26 +0800 (SGT)
Date: Wed, 09 Dec 2009 09:55:38 +0800
From: Edward Shu <Edward.Shu@Sun.COM>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
Sender: Edward.Shu@Sun.COM
To: Phi Tran <phitran@sac.sfbay.sun.com>
Cc: PSARC-ext@Sun.COM, David.Chieu@Sun.COM, Zhijun.Fu@Sun.COM,
        apic-dev@Sun.COM
Message-id: <4B1F039A.8070604@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080213)
Status: RO
Content-Length: 2382

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



From Wesley.Shao@Sun.COM Tue Dec  8 18:38:14 2009
Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB92cErn027809
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 18:38:14 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB92cEW2028338;
	Tue, 8 Dec 2009 20:38:14 -0600 (CST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD008015ZPCA00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 08 Dec 2009 18:38:13 -0800 (PST)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD004895ZPWA50@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 08 Dec 2009 18:38:13 -0800 (PST)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB92c9aS024882;
 Tue, 08 Dec 2009 18:38:13 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD008005SLRU00@fe-sfbay-09.sun.com>; Tue,
 08 Dec 2009 18:38:12 -0800 (PST)
Received: from [129.146.97.131] ([unknown] [129.146.97.131])
 by fe-sfbay-09.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD009FM5ZOSM00@fe-sfbay-09.sun.com>; Tue,
 08 Dec 2009 18:38:12 -0800 (PST)
Date: Tue, 08 Dec 2009 18:38:09 -0800
From: Wesley Shao <Wesley.Shao@Sun.COM>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F039A.8070604@sun.com>
Sender: Wesley.Shao@Sun.COM
To: Edward Shu <Edward.Shu@Sun.COM>
Cc: Phi Tran <phitran@sac.sfbay.sun.com>, PSARC-ext@Sun.COM,
        David.Chieu@Sun.COM, Zhijun.Fu@Sun.COM, apic-dev@Sun.COM
Message-id: <4B1F0D91.2050300@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1F039A.8070604@sun.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
Status: RO
Content-Length: 2349

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


From Edward.Shu@sun.com Tue Dec  8 18:44:55 2009
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB92itgs027877
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 18:44:55 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB92isei045430;
	Tue, 8 Dec 2009 19:44:54 -0700 (MST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD0090D6AUR800@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 08 Dec 2009 18:44:54 -0800 (PST)
Received: from sineb-mail-2.sun.com ([192.18.19.7])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD004H96ASWA70@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 08 Dec 2009 18:44:53 -0800 (PST)
Received: from fe-apac-05.sun.com
 (fe-apac-05.sun.com [192.18.19.176] (may be forged))
	by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB92ip8v027672; Wed,
 09 Dec 2009 02:44:51 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00M0067AXX00@mail-apac.sun.com>; Wed, 09 Dec 2009 10:44:51 +0800 (SGT)
Received: from [129.158.218.35] ([unknown] [129.158.218.35])
 by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD0087M6APOX60@mail-apac.sun.com>; Wed,
 09 Dec 2009 10:44:51 +0800 (SGT)
Date: Wed, 09 Dec 2009 10:42:03 +0800
From: Edward Shu <Edward.Shu@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F0D91.2050300@sun.com>
Sender: Edward.Shu@sun.com
To: Wesley Shao <Wesley.Shao@sun.com>
Cc: Phi Tran <phitran@sac.sfbay.sun.com>, PSARC-ext@sun.com,
        David.Chieu@sun.com, Zhijun.Fu@sun.com, apic-dev@sun.com
Message-id: <4B1F0E7B.5070109@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_pHOoUB3guSmQvAHGOnw53g)"
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1F039A.8070604@sun.com> <4B1F0D91.2050300@sun.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080213)
Status: RO
Content-Length: 6195

This is a multi-part message in MIME format.

--Boundary_(ID_pHOoUB3guSmQvAHGOnw53g)
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 7BIT

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
__________________________________________



--Boundary_(ID_pHOoUB3guSmQvAHGOnw53g)
Content-type: text/html; charset=GB2312
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
What is the APIX project? Any point for this?<br>
Wesley Shao:
<blockquote cite="mid:4B1F0D91.2050300@sun.com" type="cite">
  <pre wrap="">Edward Shu wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">See comments below.
4. Technical Description
    </pre>
    <blockquote type="cite">
      <pre wrap="">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.
  
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
They won't be after the APIX project, hence the proposal.

Wes

  </pre>
  <blockquote type="cite">
    <pre wrap="">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




    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Best Regards,
Ming.

------------------------------------------
-Edward Shu 				  	
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________

</pre>
</body>
</html>

--Boundary_(ID_pHOoUB3guSmQvAHGOnw53g)--

From Andy.Sang@sun.com Tue Dec  8 18:47:27 2009
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB92lRjS027895
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 18:47:27 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB92lRlQ047416;
	Tue, 8 Dec 2009 19:47:27 -0700 (MST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD001036F3AO00@brm-avmta-1.central.sun.com>; Tue,
 08 Dec 2009 19:47:27 -0700 (MST)
Received: from sineb-mail-1.sun.com ([192.18.19.6])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD00MSW6F17020@brm-avmta-1.central.sun.com>; Tue,
 08 Dec 2009 19:47:26 -0700 (MST)
Received: from fe-apac-06.sun.com
 (fe-apac-06.sun.com [192.18.19.177] (may be forged))
	by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB92lPdn017362; Wed,
 09 Dec 2009 02:47:25 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00H0068F8200@mail-apac.sun.com>; Wed, 09 Dec 2009 10:47:25 +0800 (SGT)
Received: from [129.158.217.78] ([unknown] [129.158.217.78])
 by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD004IN6EZ3RF0@mail-apac.sun.com>; Wed,
 09 Dec 2009 10:47:25 +0800 (SGT)
Date: Wed, 09 Dec 2009 10:41:40 +0800
From: andy sang <Andy.Sang@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F039A.8070604@sun.com>
Sender: Andy.Sang@sun.com
To: Edward Shu <Edward.Shu@sun.com>
Cc: Phi Tran <phitran@sac.sfbay.sun.com>, PSARC-ext@sun.com,
        David.Chieu@sun.com, Zhijun.Fu@sun.com, apic-dev@sun.com
Message-id: <4B1F0E64.7000601@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 8BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1F039A.8070604@sun.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090803)
Status: RO
Content-Length: 4357

In the new APIC platform, 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.  So we need both interrupt vector number and the CPU
which owns this vector are needed to identify one unique vector.

In fact, in the new APIC platform, the output of '::interrupts" command
in mdb is changed to below, it will be putback with APIC scability
project together.


pcplusmpx  (proposed output for our new APIC changes)
========================================================
:: interrupts
CPU/Vect  IRQ  IPL  Bus  Trg  Type    Share  APIC/INT#  ISR(s)
0/0x42    12   5    ISA  Edg  Fixed   1      0x0/0xc    i8042_intr
0/0x84    22   9    PCI  Lvl  Fixed   2      0x0/0x16   ohci_intr
0/0x84    22   8    PCI  Lvl  Fixed   2      0x0/0x16   audiohd_intr
1/0x81    9    9    PCI  Lvl  Fixed   1      0x0/0x9    acpi_wrapper_isr
1/0xb0    4    12   ISA  Edg  Fixed   1      0x0/0x4    asyintr
2/0x40    20   5    PCI  Lvl  Fixed   1      0x0/0x14   0
2/0x82    -    7    PCI  Edg  MSI     1      -          pepb_intr_handler
3/0x41    1    5    ISA  Edg  Fixed   1      0x0/0x1    i8042_intr
3/0x43    14   5    ISA  Edg  Fixed   1      0x0/0xe    ata_intr
3/0x60    -    6    PCI  Edg  MSI     1      -          bge_intr
3/0x83    21   9    PCI  Lvl  Fixed   1      0x0/0x15   ehci_intr
all/0xa0  -    13        Edg  IPI     1      -          poke_cpu
all/0xc0  -    14        Edg  IPI     1      -          xc_serv
all/0xd0  -    14        Edg  IPI     1      -
kcpc_hw_overflow_intr
all/0xd1  -    14        Edg  IPI     1      -          cbe_fire
all/0xd3  -    14        Edg  IPI     1      -          cbe_fire
all/0xe0  -    15        Edg  IPI     1      -          xc_serv
all/0xe1  -    15        Edg  IPI     1      -          apic_error_intr

Changes comparing to the old pcplusmp output(see 2):
 - use CPU/Vect instead of IRQ to list the interrupts info;
 - IRQ value is valid only for Fixed interrupt type.
 - shared interrupts are displayed seperatedly with its own IPL.

Thanks,
Andy


Edward Shu дµÀ:
> 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.
> 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
> 
> 
> 
> 


From Andy.Sang@Sun.COM Tue Dec  8 18:53:42 2009
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB92rgw0027988
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 18:53:42 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB92rgSn011751;
	Tue, 8 Dec 2009 18:53:42 -0800 (PST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD00J016PIJN00@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 18:53:42 -0800 (PST)
Received: from sineb-mail-1.sun.com ([192.18.19.6])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD00GRG6PGVG20@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 18:53:41 -0800 (PST)
Received: from fe-apac-06.sun.com
 (fe-apac-06.sun.com [192.18.19.177] (may be forged))
	by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB92rekw017658; Wed,
 09 Dec 2009 02:53:40 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00L006KP8K00@mail-apac.sun.com>; Wed, 09 Dec 2009 10:53:40 +0800 (SGT)
Received: from [129.158.217.78] ([unknown] [129.158.217.78])
 by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD004PZ6PF3RF0@mail-apac.sun.com>; Wed,
 09 Dec 2009 10:53:40 +0800 (SGT)
Date: Wed, 09 Dec 2009 10:47:55 +0800
From: andy sang <Andy.Sang@Sun.COM>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F0E7B.5070109@sun.com>
Sender: Andy.Sang@Sun.COM
To: Edward Shu <Edward.Shu@Sun.COM>
Cc: Wesley Shao <Wesley.Shao@Sun.COM>, Phi Tran <phitran@sac.sfbay.sun.com>,
        PSARC-ext@Sun.COM, David.Chieu@Sun.COM, Zhijun.Fu@Sun.COM,
        apic-dev@Sun.COM
Message-id: <4B1F0FDB.9060306@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 8BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1F039A.8070604@sun.com> <4B1F0D91.2050300@sun.com>
 <4B1F0E7B.5070109@sun.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090803)
Status: RO
Content-Length: 3019

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
> __________________________________________
> 
> 


From Edward.Shu@sun.com Tue Dec  8 23:32:28 2009
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB97WRdf001822
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 23:32:27 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB97WRqF002639;
	Tue, 8 Dec 2009 23:32:27 -0800 (PST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD00905JM3MS00@brm-avmta-1.central.sun.com>; Wed,
 09 Dec 2009 00:32:27 -0700 (MST)
Received: from sineb-mail-1.sun.com ([192.18.19.6])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD00EMUJM1JO70@brm-avmta-1.central.sun.com>; Wed,
 09 Dec 2009 00:32:26 -0700 (MST)
Received: from fe-apac-06.sun.com
 (fe-apac-06.sun.com [192.18.19.177] (may be forged))
	by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB97WPwO004396; Wed,
 09 Dec 2009 07:32:25 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00600JGC8X00@mail-apac.sun.com>; Wed, 09 Dec 2009 15:32:25 +0800 (SGT)
Received: from [129.158.218.35] ([unknown] [129.158.218.35])
 by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUD00AEBJLZBV80@mail-apac.sun.com>; Wed,
 09 Dec 2009 15:32:24 +0800 (SGT)
Date: Wed, 09 Dec 2009 15:29:38 +0800
From: Edward Shu <Edward.Shu@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F0FDB.9060306@Sun.COM>
Sender: Edward.Shu@sun.com
To: andy sang <Andy.Sang@sun.com>
Cc: Wesley Shao <Wesley.Shao@sun.com>, Phi Tran <phitran@sac.sfbay.sun.com>,
        PSARC-ext@sun.com, David.Chieu@sun.com, Zhijun.Fu@sun.com,
        apic-dev@sun.com
Message-id: <4B1F51E2.1040604@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_kwY+kqBXhn6xc2WT9Pl5Cw)"
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1F039A.8070604@sun.com> <4B1F0D91.2050300@sun.com>
 <4B1F0E7B.5070109@sun.com> <4B1F0FDB.9060306@Sun.COM>
User-Agent: Thunderbird 2.0.0.9 (X11/20080213)
Status: RO
Content-Length: 7928

This is a multi-part message in MIME format.

--Boundary_(ID_kwY+kqBXhn6xc2WT9Pl5Cw)
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: 8BIT

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
__________________________________________



--Boundary_(ID_kwY+kqBXhn6xc2WT9Pl5Cw)
Content-type: text/html; charset=GB2312
Content-transfer-encoding: 8BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andy,<br>
&nbsp; Thanks for your clarification.<br>
andy sang:
<blockquote cite="mid:4B1F0FDB.9060306@Sun.COM" type="cite">
  <pre wrap="">It's x86 APIC Scalability project.

Wiki:
<a class="moz-txt-link-freetext" href="http://agares.central.sun.com/twiki/bin/view/Sandbox/X86APICScalability">http://agares.central.sun.com/twiki/bin/view/Sandbox/X86APICScalability</a>

PTL:
<a class="moz-txt-link-freetext" href="http://projectlog.sfbay/ptl/dashboard.php?UniqueID=6342">http://projectlog.sfbay/ptl/dashboard.php?UniqueID=6342</a>

Thanks,
Andy

Edward Shu дµÀ:
  </pre>
  <blockquote type="cite">
    <pre wrap="">What is the APIX project? Any point for this?
Wesley Shao:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Edward Shu wrote:
  
      </pre>
      <blockquote type="cite">
        <pre wrap="">See comments below.
4. Technical Description
    
        </pre>
        <blockquote type="cite">
          <pre wrap="">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.
  
      
          </pre>
        </blockquote>
        <pre wrap="">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.
    
        </pre>
      </blockquote>
      <pre wrap="">They won't be after the APIX project, hence the proposal.

Wes

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">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




    
        </pre>
      </blockquote>
      <pre wrap="">  
      </pre>
    </blockquote>
    <pre wrap="">
-- 
Best Regards,
Ming.

------------------------------------------
-Edward Shu 				  	
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________


    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Best Regards,
Ming.

------------------------------------------
-Edward Shu 				  	
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________

</pre>
</body>
</html>

--Boundary_(ID_kwY+kqBXhn6xc2WT9Pl5Cw)--

From Zhijun.Fu@sun.com Tue Dec  8 23:43:40 2009
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB97hdcZ001883
	for <psarc-ext@sac.sfbay.sun.com>; Tue, 8 Dec 2009 23:43:39 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB97hcZ4027266;
	Wed, 9 Dec 2009 00:43:39 -0700 (MST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUD00G07K4QPO00@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 23:43:38 -0800 (PST)
Received: from sineb-mail-2.sun.com ([192.18.19.7])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUD00FP5K4PQF20@nwk-avmta-2.sfbay.sun.com>; Tue,
 08 Dec 2009 23:43:38 -0800 (PST)
Received: from fe-apac-06.sun.com
 (fe-apac-06.sun.com [192.18.19.177] (may be forged))
	by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB97hbMR014586; Wed,
 09 Dec 2009 07:43:37 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUD00E00K31CQ00@mail-apac.sun.com>; Wed, 09 Dec 2009 15:43:37 +0800 (SGT)
Received: from [10.0.254.241] ([unknown] [192.9.202.228])
 by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit
 (built Jul  2 2009)) with ESMTPSA id <0KUD00MEYK4N0S50@mail-apac.sun.com>; Wed,
 09 Dec 2009 15:43:37 +0800 (SGT)
Date: Wed, 09 Dec 2009 15:43:08 +0800
From: Zhijun Fu <Zhijun.Fu@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1D8380.1010404@sun.com>
Sender: Zhijun.Fu@sun.com
To: "Garrett D'Amore" <gdamore@sun.com>
Cc: Phi Tran <phitran@sac.sfbay.sun.com>, PSARC-ext@sun.com,
        David.Chieu@sun.com, apic-dev@sun.com
Message-id: <4B1F550C.6050808@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1D8380.1010404@sun.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
Status: RO
Content-Length: 1391

Garrett D'Amore wrote:
> Personally, I find the new syntax and the new output a bit awkward -- 
> anyone not intimately familiar with the tool is going to have trouble 
> understanding what 0x1,0x8  means.
>
> I think I'd rather keep the two separate in the output, and add a new 
> switch (-p ?) for the "original" cpu id for x86 platforms.
Thanks Garrett for the comments.

On the input side, user need to uniquely specify which interrupt(s) to 
show/retarget,
and on x86 platforms an interrupt will be uniquely identified by a 
(cpuid, vector#)
pair, thus we choose this pair as a representation for an interrupt, 
something like
0x1, 0x8.

Otherwise we'll have to add a new option for cpu and check for both options,
     -i <vector#> -p cpuid
with this we have to verify and report error if users use one but not both,
that could lower user friendly.

Assuming the above, on the output side we'll need the new output
as well to be to be consistent with the input side. That also works
more friendly with scripts. And with examples in manpages probably
it would be less a problem for new users to understand things like
0x1, 0x8. Or do you still fell strong enough that the original
verbose output should be preserved?

Thanks,
Robin








>
>    - Garrett
>
Thanks for the suggestion, Garrett.

On x86 an interrupt will be uniquely identified by a (cpuid, vector#) pair,
thus 0x1,




From gdamore@sun.com Wed Dec  9 07:45:43 2009
Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9FjgPb021499
	for <psarc-ext@sac.sfbay.sun.com>; Wed, 9 Dec 2009 07:45:42 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9Fhu9A024222;
	Wed, 9 Dec 2009 09:43:57 -0600 (CST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUE00A1X6D9FL00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 09 Dec 2009 07:43:57 -0800 (PST)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUE001U26D7NL40@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 09 Dec 2009 07:43:55 -0800 (PST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9FhtHw020930;
 Wed, 09 Dec 2009 07:43:55 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUE000006D7PY00@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 07:43:55 -0800 (PST)
Received: from [192.168.251.11] ([unknown] [76.93.15.33])
 by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUE00DZI6D6AI20@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 07:43:55 -0800 (PST)
Date: Wed, 09 Dec 2009 07:43:54 -0800
From: "Garrett D'Amore" <gdamore@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1F550C.6050808@sun.com>
Sender: Garrett.Damore@sun.com
To: Zhijun Fu <Zhijun.Fu@sun.com>
Cc: Phi Tran <phitran@sac.sfbay.sun.com>, PSARC-ext@sun.com,
        David.Chieu@sun.com, apic-dev@sun.com
Message-id: <4B1FC5BA.4060406@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1D8380.1010404@sun.com> <4B1F550C.6050808@sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20091013)
Status: RO
Content-Length: 2106

Zhijun Fu wrote:
> Garrett D'Amore wrote:
>> Personally, I find the new syntax and the new output a bit awkward -- 
>> anyone not intimately familiar with the tool is going to have trouble 
>> understanding what 0x1,0x8  means.
>>
>> I think I'd rather keep the two separate in the output, and add a new 
>> switch (-p ?) for the "original" cpu id for x86 platforms.
> Thanks Garrett for the comments.
>
> On the input side, user need to uniquely specify which interrupt(s) to 
> show/retarget,
> and on x86 platforms an interrupt will be uniquely identified by a 
> (cpuid, vector#)
> pair, thus we choose this pair as a representation for an interrupt, 
> something like
> 0x1, 0x8.
>
> Otherwise we'll have to add a new option for cpu and check for both 
> options,
>     -i <vector#> -p cpuid
> with this we have to verify and report error if users use one but not 
> both,
> that could lower user friendly.
>
> Assuming the above, on the output side we'll need the new output
> as well to be to be consistent with the input side. That also works
> more friendly with scripts. And with examples in manpages probably
> it would be less a problem for new users to understand things like
> 0x1, 0x8. Or do you still fell strong enough that the original
> verbose output should be preserved?

I'm not entirely sure I agree with your stance that adding a new option 
is less user friendly, but I do see that having the tool behave 
differently on SPARC vs. x86 would be unfortunate.

Is there a way to encode the CPU in the vector number?  Perhaps use a 
value like x, where x = cpu * 256 + vector?   (The question here is, do 
users of this tool have any reason to care about the actual value of the 
vector number?)   If you encode the CPU into the vector number 
numerically, then you can do this without really changing any of the 
command line options or output formats, if you wanted to.

    - Garrett
>
> Thanks,
> Robin
>
>
>
>
>
>
>
>
>>
>>    - Garrett
>>
> Thanks for the suggestion, Garrett.
>
> On x86 an interrupt will be uniquely identified by a (cpuid, vector#) 
> pair,
> thus 0x1,
>
>
>


From Wesley.Shao@sun.com Wed Dec  9 10:08:28 2009
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9I8RhJ000180
	for <psarc-ext@sac.sfbay.sun.com>; Wed, 9 Dec 2009 10:08:28 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB9I8QfS024506;
	Wed, 9 Dec 2009 11:08:27 -0700 (MST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUE0080BD232A00@nwk-avmta-2.sfbay.sun.com>; Wed,
 09 Dec 2009 10:08:27 -0800 (PST)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUE000MND22R7A0@nwk-avmta-2.sfbay.sun.com>; Wed,
 09 Dec 2009 10:08:26 -0800 (PST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9I8QhR007446;
 Wed, 09 Dec 2009 10:08:26 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUE00C00C1J6700@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 10:08:26 -0800 (PST)
Received: from [129.146.96.108] ([unknown] [129.146.96.108])
 by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUE0066MD1SWW30@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 10:08:20 -0800 (PST)
Date: Wed, 09 Dec 2009 10:05:52 -0800
From: Wesley Shao <Wesley.Shao@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1FC5BA.4060406@sun.com>
Sender: Wesley.Shao@sun.com
To: "Garrett D'Amore" <gdamore@sun.com>
Cc: Zhijun Fu <Zhijun.Fu@sun.com>, Phi Tran <phitran@sac.sfbay.sun.com>,
        PSARC-ext@sun.com, David.Chieu@sun.com, apic-dev@sun.com
Message-id: <4B1FE700.3040100@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1D8380.1010404@sun.com> <4B1F550C.6050808@sun.com>
 <4B1FC5BA.4060406@sun.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090323)
Status: RO
Content-Length: 3156

Garrett D'Amore wrote:
> Zhijun Fu wrote:
>> Garrett D'Amore wrote:
>>> Personally, I find the new syntax and the new output a bit awkward -- 
>>> anyone not intimately familiar with the tool is going to have trouble 
>>> understanding what 0x1,0x8  means.
>>>
>>> I think I'd rather keep the two separate in the output, and add a new 
>>> switch (-p ?) for the "original" cpu id for x86 platforms.
>> Thanks Garrett for the comments.
>>
>> On the input side, user need to uniquely specify which interrupt(s) to 
>> show/retarget,
>> and on x86 platforms an interrupt will be uniquely identified by a 
>> (cpuid, vector#)
>> pair, thus we choose this pair as a representation for an interrupt, 
>> something like
>> 0x1, 0x8.
>>
>> Otherwise we'll have to add a new option for cpu and check for both 
>> options,
>>     -i <vector#> -p cpuid
>> with this we have to verify and report error if users use one but not 
>> both,
>> that could lower user friendly.
>>
>> Assuming the above, on the output side we'll need the new output
>> as well to be to be consistent with the input side. That also works
>> more friendly with scripts. And with examples in manpages probably
>> it would be less a problem for new users to understand things like
>> 0x1, 0x8. Or do you still fell strong enough that the original
>> verbose output should be preserved?
> 
> I'm not entirely sure I agree with your stance that adding a new option 
> is less user friendly, but I do see that having the tool behave 
> differently on SPARC vs. x86 would be unfortunate.
> 
> Is there a way to encode the CPU in the vector number?  Perhaps use a 
> value like x, where x = cpu * 256 + vector?   (The question here is, do 
> users of this tool have any reason to care about the actual value of the 
> vector number?)   If you encode the CPU into the vector number 
> numerically, then you can do this without really changing any of the 
> command line options or output formats, if you wanted to.

Each device can have many MSIs with each MSI taking a unique vector
on any given cpu. Without knowing exactly which vector on which cpu,
the tool can't be sure which MSI is being addressed.

In terms of encoding cpu number into vector numbers in general, it
has been discussed within the project team extensively. It actually
adds more obscurity. The cpu numbers don't have to be contiguous with
cpu hotplug features, it can go way beyond 256 in to full 32-bit with
some recent hardware evolution, and on top of that converting between
hex and decimal becomes a challenge for users since the tool needs
to follow the convention that default input format is decimal, 0x for
hex, etc.

The way we are heading on x86 platform, hardware and finally software,
each vector belongs to a cpu. It would be meaningless to mention a
vector number without knowing which logical cpu. I think the tool is
doing the right thing to bundle them together.

Wes

> 
>    - Garrett
>>
>> Thanks,
>> Robin
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>    - Garrett
>>>
>> Thanks for the suggestion, Garrett.
>>
>> On x86 an interrupt will be uniquely identified by a (cpuid, vector#) 
>> pair,
>> thus 0x1,
>>
>>
>>
> 


From gdamore@sun.com Wed Dec  9 11:28:15 2009
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9JSFr2001652
	for <psarc-ext@sac.sfbay.sun.com>; Wed, 9 Dec 2009 11:28:15 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB9JSFEl021647;
	Wed, 9 Dec 2009 12:28:15 -0700 (MST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUE00C01GR2PJ00@brm-avmta-1.central.sun.com>; Wed,
 09 Dec 2009 12:28:15 -0700 (MST)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUE00C18GR2NI00@brm-avmta-1.central.sun.com>; Wed,
 09 Dec 2009 12:28:14 -0700 (MST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129])
	by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9JSEmw004564;
 Wed, 09 Dec 2009 11:28:14 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUE00700GNGYV00@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 11:28:14 -0800 (PST)
Received: from [192.168.251.11] ([unknown] [76.93.15.33])
 by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KUE003CLGR0SME0@fe-sfbay-10.sun.com>; Wed,
 09 Dec 2009 11:28:13 -0800 (PST)
Date: Wed, 09 Dec 2009 11:28:12 -0800
From: "Garrett D'Amore" <gdamore@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1FE700.3040100@sun.com>
Sender: Garrett.Damore@sun.com
To: Wesley Shao <Wesley.Shao@sun.com>
Cc: Zhijun Fu <Zhijun.Fu@sun.com>, Phi Tran <phitran@sac.sfbay.sun.com>,
        PSARC-ext@sun.com, David.Chieu@sun.com, apic-dev@sun.com
Message-id: <4B1FFA4C.4000404@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1D8380.1010404@sun.com> <4B1F550C.6050808@sun.com>
 <4B1FC5BA.4060406@sun.com> <4B1FE700.3040100@sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20091013)
Status: RO
Content-Length: 3381

Wesley Shao wrote:
> Garrett D'Amore wrote:
>> Zhijun Fu wrote:
>>> Garrett D'Amore wrote:
>>>> Personally, I find the new syntax and the new output a bit awkward 
>>>> -- anyone not intimately familiar with the tool is going to have 
>>>> trouble understanding what 0x1,0x8  means.
>>>>
>>>> I think I'd rather keep the two separate in the output, and add a 
>>>> new switch (-p ?) for the "original" cpu id for x86 platforms.
>>> Thanks Garrett for the comments.
>>>
>>> On the input side, user need to uniquely specify which interrupt(s) 
>>> to show/retarget,
>>> and on x86 platforms an interrupt will be uniquely identified by a 
>>> (cpuid, vector#)
>>> pair, thus we choose this pair as a representation for an interrupt, 
>>> something like
>>> 0x1, 0x8.
>>>
>>> Otherwise we'll have to add a new option for cpu and check for both 
>>> options,
>>>     -i <vector#> -p cpuid
>>> with this we have to verify and report error if users use one but 
>>> not both,
>>> that could lower user friendly.
>>>
>>> Assuming the above, on the output side we'll need the new output
>>> as well to be to be consistent with the input side. That also works
>>> more friendly with scripts. And with examples in manpages probably
>>> it would be less a problem for new users to understand things like
>>> 0x1, 0x8. Or do you still fell strong enough that the original
>>> verbose output should be preserved?
>>
>> I'm not entirely sure I agree with your stance that adding a new 
>> option is less user friendly, but I do see that having the tool 
>> behave differently on SPARC vs. x86 would be unfortunate.
>>
>> Is there a way to encode the CPU in the vector number?  Perhaps use a 
>> value like x, where x = cpu * 256 + vector?   (The question here is, 
>> do users of this tool have any reason to care about the actual value 
>> of the vector number?)   If you encode the CPU into the vector number 
>> numerically, then you can do this without really changing any of the 
>> command line options or output formats, if you wanted to.
>
> Each device can have many MSIs with each MSI taking a unique vector
> on any given cpu. Without knowing exactly which vector on which cpu,
> the tool can't be sure which MSI is being addressed.
>
> In terms of encoding cpu number into vector numbers in general, it
> has been discussed within the project team extensively. It actually
> adds more obscurity. The cpu numbers don't have to be contiguous with
> cpu hotplug features, it can go way beyond 256 in to full 32-bit with
> some recent hardware evolution, and on top of that converting between
> hex and decimal becomes a challenge for users since the tool needs
> to follow the convention that default input format is decimal, 0x for
> hex, etc.
>
> The way we are heading on x86 platform, hardware and finally software,
> each vector belongs to a cpu. It would be meaningless to mention a
> vector number without knowing which logical cpu. I think the tool is
> doing the right thing to bundle them together.

Thanks Wesley.  I think we've talked about this enough ... its got a +1 
from me now.

    - Garrett
>
> Wes
>
>>
>>    - Garrett
>>>
>>> Thanks,
>>> Robin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>    - Garrett
>>>>
>>> Thanks for the suggestion, Garrett.
>>>
>>> On x86 an interrupt will be uniquely identified by a (cpuid, 
>>> vector#) pair,
>>> thus 0x1,
>>>
>>>
>>>
>>
>


From Phi.Tran@sun.com Wed Dec 16 10:14:35 2009
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBGIEZaD026835
	for <psarc-ext@sac.sfbay.sun.com>; Wed, 16 Dec 2009 10:14:35 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBGIEXUE002075;
	Wed, 16 Dec 2009 10:14:34 -0800 (PST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KUR0081FC09HB00@brm-avmta-1.central.sun.com>; Wed,
 16 Dec 2009 11:14:33 -0700 (MST)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KUR007LCC08TH00@brm-avmta-1.central.sun.com>; Wed,
 16 Dec 2009 11:14:32 -0700 (MST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129])
	by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBGIEWMF005615;
 Wed, 16 Dec 2009 10:14:32 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KUR00200AHPJF00@fe-sfbay-10.sun.com>; Wed,
 16 Dec 2009 10:14:32 -0800 (PST)
Received: from [129.153.2.14] ([unknown] [129.153.2.14])
 by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit
 (built Jul  2 2009)) with ESMTPSA id <0KUR00LYZC07OW30@fe-sfbay-10.sun.com>;
 Wed, 16 Dec 2009 10:14:32 -0800 (PST)
Date: Wed, 16 Dec 2009 10:14:31 -0800
From: Phi Tran <Phi.Tran@sun.com>
Subject: Re: Pcitool Extensions [PSARC/2009/665 FastTrack timeout 12/11/2009]
In-reply-to: <4B1FFA4C.4000404@sun.com>
Sender: Phi.Tran@sun.com
To: PSARC-ext@sun.com
Cc: Zhijun Fu <Zhijun.Fu@sun.com>, David.Chieu@sun.com, apic-dev@sun.com
Message-id: <4B292387.2040406@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200912072228.nB7MSJI6004568@sac.sfbay.sun.com>
 <4B1D8380.1010404@sun.com> <4B1F550C.6050808@sun.com>
 <4B1FC5BA.4060406@sun.com> <4B1FE700.3040100@sun.com>
 <4B1FFA4C.4000404@sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090910)
Status: RO
Content-Length: 44

This case was approved at PSARC today.

Phi