From gdamore@sun.com Wed Apr 15 13:41:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3FKfeP7026905 for ; Wed, 15 Apr 2009 13:41:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3FKfYU8004566 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 15 Apr 2009 21:41:39 +0100 (BST) 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 <0KI500E11THC1700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:41:36 -0600 (MDT) 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 <0KI5008HXTHBPYD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:41:35 -0600 (MDT) 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 n3FKfZF6014971 for ; Wed, 15 Apr 2009 13:41:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI500100T5CUE00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 13:41:35 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI500H64TGY9J50@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 13:41:22 -0700 (PDT) Date: Wed, 15 Apr 2009 13:41:22 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/215 PCITool Public Interrupts Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49E64672.4090109@sun.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO X-Lines: 2 Content-Type: text/plain; format="flowed"; charset="ISO-8859-1" Content-Length: 35 This is another test. Ignore it. From gd78059@sac.sfbay.sun.com Wed Apr 15 13:42:14 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3FKgDA7026990 for ; Wed, 15 Apr 2009 13:42:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3FKg8M6005043 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 15 Apr 2009 21:42:12 +0100 (BST) 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 <0KI500117TI9Q200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 15 Apr 2009 13:42:09 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI5000NGTI8UH10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 15 Apr 2009 13:42:08 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3FKg8Hm032514 for ; Wed, 15 Apr 2009 13:42:08 -0700 (PDT) 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 n3FKg7Gs026984 for ; Wed, 15 Apr 2009 13:42:07 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3FKg7jN026983 for psarc-ext@sun.com; Wed, 15 Apr 2009 13:42:07 -0700 (PDT) Date: Wed, 15 Apr 2009 13:42:07 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: PSARC 2009/215 PCITool Public Interrupts To: psarc-ext@sun.com Message-id: <200904152042.n3FKg7jN026983@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 37 X-Lines: 2 And another, hopefully final, test. From gdamore@sun.com Wed Apr 15 13:46:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3FKkpwM027186 for ; Wed, 15 Apr 2009 13:46:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3FKkn4u007498 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 15 Apr 2009 21:46:50 +0100 (BST) 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 <0KI500E07TQ2K800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:46:50 -0600 (MDT) 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 <0KI500E3JTQ0HU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:46:49 -0600 (MDT) 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 n3FKkmak027821 for ; Wed, 15 Apr 2009 13:46:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI500800TH3KW00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 13:46:48 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI5004JFTPUJ430@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 13:46:43 -0700 (PDT) Date: Wed, 15 Apr 2009 13:46:42 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/215 PCITool Public Interrupts Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49E647B2.7080908@sun.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO X-Lines: 86 Content-Type: text/plain; format="flowed"; charset="ISO-8859-1" Content-Length: 3059 As the ARC tools seem to have "eaten" my previous posts, we're restarting this case with a new time out one week from today (timeout 04/22/2009). The project team is requesting patch binding, and volatile commitment. This is filed on behalf of Erwin Tsaur. Proposal follows: Project Description: PCITool was previously conceived in PSARC 2005/232, but was intended as an internal only tool. This case would make the command line interface, pcitool, available to external customers. PCITool is required to re-assign and balance interrupt loads on multi-CPU systems. Public access to this functionality is required if Sun wishes to claim performance advantages at system RR. It will allow independent 3rd parties to verify and achieve the posted performance numbers. Without this tool TPC-C benchmarks for Batoka+ cannot be published Risks and Assumptions: PCITool allows privileged users to remap interrupt-CPU bindings safely. It also has the capability of accessing, including modifying device registers in the load/store domain. Such actions may result in a performance and functional behavior change of the system. The device register access functionality will be kept undocumented. Man page and on-line help will only mentioned interrupt binding options. Technical Description: A new package, SUNWio-tools, will be created and released to the general public. Zones will be limited as defined in the pkginfo template. SUNW_PKG_ALLZONES="true" SUNW_PKG_HOLLOW="true" SUNW_PKG_THISZONE="false" The above settings will prevent pcitool from being installed in a non-global zone. PCITool will only work in a global zone, since it is not possible to export nodes or the minor nodes used by pcitool in /devices/xxx to a non-global zone. Bug/RFE Number(s): 6799018 pcitool should be available as a supported tool on Solaris 10 In Scope: Productize PCITool through a Solaris package. Out of Scope: Changing PCITool in any significant way. Interfaces: pcitool is an admin tool. pcitool -i [ ino= ] [ -r | -w cpu= ] [ -v ] -i [ ino= ] changes or retrieves current CPU for interrupts of given nexus and optionally given ino. Ino must be selected if -w specified. If no ino is selected (as for displaying), all will be selected. -w cpu= to change an ino<->CPU binding. -r for displaying ino<->CPU bindings of all selected inos on a given nexus. All relevant enabled inos supporting non-nexus device interrupts will be printed. For each printed ino, all supported devices and their CPU binding will be displayed. On some platforms, inos dedicated to the root nexus will be shown and marked with "(Internal)". -v gives verbose output for all modes. Doc Impact: A new PCITool manpage will be created with only the interrupt-CPU binding options. Reference Documents: PSARC 2005/232 From gww@sac.sfbay.sun.com Tue Apr 21 13:46:09 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 n3LKk9C4007881 for ; Tue, 21 Apr 2009 13:46:09 -0700 (PDT) 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.2) with ESMTP id n3LKk6tQ044856; Tue, 21 Apr 2009 14:46:08 -0600 (MDT) 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 <0KIG0084ZXOVZ000@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 13:46:07 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG006SVXOTGQ30@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 13:46:05 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LKk5iD044353; Tue, 21 Apr 2009 13:46:05 -0700 (PDT) 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 n3LKk5WA007878; Tue, 21 Apr 2009 13:46:05 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3LKk5lX007877; Tue, 21 Apr 2009 13:46:05 -0700 (PDT) Date: Tue, 21 Apr 2009 13:46:05 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: PSARC-ext@sun.com, gdamore@sun.com Message-id: <200904212046.n3LKk5lX007877@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 679 X-Lines: 17 > Project Description: > PCITool was previously conceived in PSARC 2005/232, but was > intended as an internal only tool. This case would make the > command line interface, pcitool, available to external customers. My recollection from 2005/232 was there was a discussion about non-standard install places. How was that resolved? > Risks and Assumptions: > PCITool allows privileged users to remap interrupt-CPU bindings What's a "privileged user"? What Rights Profile will pcitool be in? Again my recollection from 2005/232 is that "all" privileges is required. Is that still the case? Is there also some specific userID that's necessary? Gary.. From Peter.Dennis@Sun.COM Wed Apr 22 04:00:29 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 n3MB0Slv020089 for ; Wed, 22 Apr 2009 04:00:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3MB0SNW021713 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 04:00:28 -0700 (PDT) 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 <0KII00G0118SCN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 04:00:28 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII00EGJ18RYR40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 04:00:28 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MB0Ria020420 for ; Wed, 22 Apr 2009 11:00:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIH00200ZVKIQ00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:00:27 +0100 (BST) Received: from [129.156.173.66] ([unknown] [129.156.173.66]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KII00H7T18EHTA0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:00:14 +0100 (BST) Date: Wed, 22 Apr 2009 12:00:14 +0100 From: Peter Dennis - Sustaining Engineer Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49E647B2.7080908@sun.com> Sender: Peter.Dennis@Sun.COM To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <49EEF8BE.4040306@sun.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49E647B2.7080908@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO X-Lines: 97 Content-Type: text/plain; format="flowed"; charset="ISO-8859-1" Content-Length: 3641 What is the interaction with intrd (PSARC/2004/199) here whose purpose is to balance interrupts across CPU's ? Does the use of this tool imply that the intrd service should be disabled (could they end up conflicting with each other) ? Thanks pete Garrett D'Amore wrote: > > As the ARC tools seem to have "eaten" my previous posts, we're > restarting this case with a new time out one week from today (timeout > 04/22/2009). > > The project team is requesting patch binding, and volatile commitment. > This is filed on behalf of Erwin Tsaur. > > Proposal follows: > > Project Description: > PCITool was previously conceived in PSARC 2005/232, but was > intended as an internal only tool. This case would make the > command line interface, pcitool, available to external customers. > > PCITool is required to re-assign and balance interrupt loads on > multi-CPU systems. Public access to this functionality is > required if Sun wishes to claim performance advantages at system > RR. > > It will allow independent 3rd parties to verify and achieve the > posted performance numbers. Without this tool TPC-C benchmarks > for Batoka+ cannot be published > > Risks and Assumptions: > PCITool allows privileged users to remap interrupt-CPU bindings > safely. It also has the capability of accessing, including > modifying device registers in the load/store domain. Such actions > may result in a performance and functional behavior change of the > system. > > The device register access functionality will be kept > undocumented. Man page and on-line help will only mentioned > interrupt binding options. > > Technical Description: > A new package, SUNWio-tools, will be created and released to the > general public. > > Zones will be limited as defined in the pkginfo template. > SUNW_PKG_ALLZONES="true" > SUNW_PKG_HOLLOW="true" > SUNW_PKG_THISZONE="false" > > The above settings will prevent pcitool from being installed in a > non-global zone. PCITool will only work in a global zone, since > it is not possible to export nodes or the minor nodes used by > pcitool in /devices/xxx to a non-global zone. > > Bug/RFE Number(s): > 6799018 pcitool should be available as a supported tool on Solaris 10 > In Scope: > Productize PCITool through a Solaris package. > > Out of Scope: > Changing PCITool in any significant way. > Interfaces: > pcitool is an admin tool. > > pcitool -i [ ino= ] [ -r | -w cpu= ] [ -v ] > > -i [ ino= ] changes or retrieves current CPU for interrupts > of given nexus and optionally given ino. Ino must be selected if > -w specified. If no ino is selected (as for displaying), all > will be selected. > > -w cpu= to change an ino<->CPU binding. > > -r for displaying ino<->CPU bindings of all selected inos on a > given nexus. All relevant enabled inos supporting non-nexus > device interrupts will be printed. For each printed ino, all > supported devices and their CPU binding will be displayed. On > some platforms, inos dedicated to the root nexus will be shown > and marked with "(Internal)". > > -v gives verbose output for all modes. > > Doc Impact: > A new PCITool manpage will be created with only the interrupt-CPU > binding options. > Reference Documents: > PSARC 2005/232 > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Erwin.Tsaur@sun.com Wed Apr 22 10:01:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3MH1bb7018671 for ; Wed, 22 Apr 2009 10:01:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MH1UJk003975; Wed, 22 Apr 2009 18:01:36 +0100 (BST) 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 <0KII00C19HYNU800@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 11:01:35 -0600 (MDT) 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 <0KII006A3HYMMO50@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 11:01:34 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MH1YVk015284; Wed, 22 Apr 2009 10:01:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KII00F00H181H00@fe-sfbay-09.sun.com>; Wed, 22 Apr 2009 10:01:34 -0700 (PDT) Received: from [10.6.93.21] ([unknown] [10.6.93.21]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KII00GY9HYGI060@fe-sfbay-09.sun.com>; Wed, 22 Apr 2009 10:01:29 -0700 (PDT) Date: Wed, 22 Apr 2009 09:56:48 -0700 From: Erwin T Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts Sender: Erwin.Tsaur@sun.com To: PSARC-ext@sun.com, pci-core@sun.com, Gary Winiger , Alan Slivensky Reply-to: Erwin.Tsaur@sun.com Message-id: <49EF4C50.7060301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 913 Some emails were sent to I'm not CC'ed on any of them.. From: Gary Winiger > Project Description: > PCITool was previously conceived in PSARC 2005/232, but was > intended as an internal only tool. This case would make the > command line interface, pcitool, available to external customers. My recollection from 2005/232 was there was a discussion about non-standard install places. How was that resolved? I wasn't part of that discussion back then. Not sure what that would be about. > Risks and Assumptions: > PCITool allows privileged users to remap interrupt-CPU bindings What's a "privileged user"? What Rights Profile will pcitool be in? Again my recollection from 2005/232 is that "all" privileges is required. Is that still the case? Is there also some specific userID that's necessary Same rights nothing has changed, except some documentation. From Peter.Dennis@Sun.COM Wed Apr 22 04:00:29 2009 Status: RO What is the interaction with intrd (PSARC/2004/199) here whose purpose is to balance interrupts across CPU's ? Does the use of this tool imply that the intrd service should be disabled (could they end up conflicting with each other) ? Yes you may need to. It's up to the usage model by PAE/SAE who is requesting this tool. It's a low level tool From gww@sac.sfbay.sun.com Wed Apr 22 14:56:41 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3MLuewO024333 for ; Wed, 22 Apr 2009 14:56:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3MLud3A001385; Thu, 23 Apr 2009 05:56:40 +0800 (SGT) 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 <0KII0060BVMEPI00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Apr 2009 14:56:38 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII00J3KVMEK9E0@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Apr 2009 14:56:38 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MLubHm053914; Wed, 22 Apr 2009 14:56:37 -0700 (PDT) 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 n3MLublD024331; Wed, 22 Apr 2009 14:56:37 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3MLubRf024330; Wed, 22 Apr 2009 14:56:37 -0700 (PDT) Date: Wed, 22 Apr 2009 14:56:37 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: Alan.Slivensky@sun.com, Erwin.Tsaur@sun.com, PSARC-ext@sun.com, gww@sac.sfbay.sun.com, pci-core@sun.com Message-id: <200904222156.n3MLubRf024330@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1954 > From: Gary Winiger > > Project Description: > > PCITool was previously conceived in PSARC 2005/232, but was > > intended as an internal only tool. This case would make the > > command line interface, pcitool, available to external customers. > > My recollection from 2005/232 was there was a discussion > about non-standard install places. How was that resolved? > > I wasn't part of that discussion back then. Not sure what that would be about. As the project is largely relying on that case with was about an unbundled integration, it seems to me appropriate for the project team to review the basis of this case and ensure that the issues that were raised there are resolved now. Saying something is not shipped with the WOS, but as an unbundled with a limited set of users leads to different packaging and installation that something shipping with the WOS. Since a patch binding has been requested, the WOS in this case is S10. > > Risks and Assumptions: > > PCITool allows privileged users to remap interrupt-CPU bindings > > What's a "privileged user"? What Rights Profile will pcitool > be in? Again my recollection from 2005/232 is that "all" > privileges is required. Is that still the case? Is there > also some specific userID that's necessary > > Same rights nothing has changed, except some documentation. Again there was a discussion of privileges that didn't seem to converge. From the man page, I could read that the only privilege needed is sys_res_config. 2005/233 seemed to imply privs=all. This case materials doesn't define how, now that pcitool will be provided as part of the WOS, the sys_res_config privilege is granted to pcitool. Specifically, what Rights Profile and is sys_res_config the only privilege granted? Are there any uid requirements? Nit: the case mail says volatile commitment, while the man page says project private. Gary.. From Erwin.Tsaur@sun.com Wed Apr 22 22:05:38 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 n3N55cot023725 for ; Wed, 22 Apr 2009 22:05:38 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3N55boi019431; Wed, 22 Apr 2009 22:05:38 -0700 (PDT) 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 <0KIJ00L0DFHEE700@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 23:05:38 -0600 (MDT) 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 <0KIJ00KCFFHDNW90@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 23:05:37 -0600 (MDT) 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 n3N55blS016588; Wed, 22 Apr 2009 22:05:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIJ00K00FCVDF00@fe-sfbay-10.sun.com>; Wed, 22 Apr 2009 22:05:37 -0700 (PDT) Received: from [129.150.16.45] ([unknown] [129.150.16.45]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIJ00ATGFHBRVB0@fe-sfbay-10.sun.com>; Wed, 22 Apr 2009 22:05:35 -0700 (PDT) Date: Wed, 22 Apr 2009 22:05:39 -0700 From: Erwin Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <200904222156.n3MLubRf024330@sac.sfbay.sun.com> Sender: Erwin.Tsaur@sun.com To: Gary Winiger Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49EFF723.8040605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904222156.n3MLubRf024330@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 2488 Gary Winiger wrote: >> From: Gary Winiger >> >>> Project Description: >>> PCITool was previously conceived in PSARC 2005/232, but was >>> intended as an internal only tool. This case would make the >>> command line interface, pcitool, available to external customers. >>> >> My recollection from 2005/232 was there was a discussion >> about non-standard install places. How was that resolved? >> >> I wasn't part of that discussion back then. Not sure what that would be about. >> > > As the project is largely relying on that case with was about > an unbundled integration, it seems to me appropriate for the > project team to review the basis of this case and ensure that > the issues that were raised there are resolved now. > Saying something is not shipped with the WOS, but as an unbundled > with a limited set of users leads to different packaging and > installation that something shipping with the WOS. Since a > patch binding has been requested, the WOS in this case is > S10. > Yes good point. There is another discussion going on about this whole packaging issue. It is definitely being scrutinized as the requesters for this tool all have their own requirements and such. > >>> Risks and Assumptions: >>> PCITool allows privileged users to remap interrupt-CPU bindings >>> >> What's a "privileged user"? What Rights Profile will pcitool >> be in? Again my recollection from 2005/232 is that "all" >> privileges is required. Is that still the case? Is there >> also some specific userID that's necessary >> >> Same rights nothing has changed, except some documentation. >> > > Again there was a discussion of privileges that didn't > seem to converge. From the man page, I could read that > the only privilege needed is sys_res_config. 2005/233 > seemed to imply privs=all. This case materials doesn't > define how, now that pcitool will be provided as part of > the WOS, the sys_res_config privilege is granted to > pcitool. Specifically, what Rights Profile and is sys_res_config > the only privilege granted? Are there any uid requirements? > The privileges really refer to the ioctls which this package has nothing to do with. We are only dealing with the userland binary. > Nit: the case mail says volatile commitment, while the man page > says project private. > yes, we caught that and have an update.. It's volatile commitment. > Gary.. > From gww@sac.sfbay.sun.com Thu Apr 23 11:26:10 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3NIQ9MA027849 for ; Thu, 23 Apr 2009 11:26:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3NIQ0v8003330; Fri, 24 Apr 2009 02:26:08 +0800 (SGT) 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 <0KIK00G1FGJIS500@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Apr 2009 11:26:06 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIK00KB0GJHTPF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Apr 2009 11:26:05 -0700 (PDT) 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.2) with ESMTP id n3NIQ4Et033602; Thu, 23 Apr 2009 11:26:04 -0700 (PDT) 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 n3NIQ4cH027847; Thu, 23 Apr 2009 11:26:04 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3NIQ4PF027846; Thu, 23 Apr 2009 11:26:04 -0700 (PDT) Date: Thu, 23 Apr 2009 11:26:04 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: Erwin.Tsaur@sun.com, gww@sac.sfbay.sun.com Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2467 > >> My recollection from 2005/232 was there was a discussion > >> about non-standard install places. How was that resolved? > >> > >> I wasn't part of that discussion back then. Not sure what that would be about. > >> > > > > As the project is largely relying on that case with was about > > an unbundled integration, it seems to me appropriate for the > > project team to review the basis of this case and ensure that > > the issues that were raised there are resolved now. > > Saying something is not shipped with the WOS, but as an unbundled > > with a limited set of users leads to different packaging and > > installation that something shipping with the WOS. Since a > > patch binding has been requested, the WOS in this case is > > S10. > > > Yes good point. There is another discussion going on about this whole > packaging issue. It is definitely being scrutinized as the requesters > for this tool all have their own requirements and such. If this is still being discussed, isn't the case premature? Shouldn't this case be in waiting need spec until all relevant peripheral discussions have completed? > >>> Risks and Assumptions: > >>> PCITool allows privileged users to remap interrupt-CPU bindings > >>> > >> What's a "privileged user"? What Rights Profile will pcitool > >> be in? Again my recollection from 2005/232 is that "all" > >> privileges is required. Is that still the case? Is there > >> also some specific userID that's necessary > >> > >> Same rights nothing has changed, except some documentation. > >> > > > > Again there was a discussion of privileges that didn't > > seem to converge. From the man page, I could read that > > the only privilege needed is sys_res_config. 2005/233 > > seemed to imply privs=all. This case materials doesn't > > define how, now that pcitool will be provided as part of > > the WOS, the sys_res_config privilege is granted to > > pcitool. Specifically, what Rights Profile and is sys_res_config > > the only privilege granted? Are there any uid requirements? > > > The privileges really refer to the ioctls which this package has nothing > to do with. We are only dealing with the userland binary. Ok, the privileges refer to the ioctls. I presume the userland binary calls the ioctls. Is the only privilege the userland binary requires sys_res_config? How does the userland binary gain this or any other privileges? Gary.. From Erwin.Tsaur@sun.com Thu Apr 23 13:35: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 n3NKZed2025681 for ; Thu, 23 Apr 2009 13:35:40 -0700 (PDT) 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.2) with ESMTP id n3NKZYBd018343; Thu, 23 Apr 2009 14:35:39 -0600 (MDT) 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 <0KIK00HGTMJDQN00@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Apr 2009 13:35:37 -0700 (PDT) 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 <0KIK009SUMFSNL90@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Apr 2009 13:33:28 -0700 (PDT) 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 n3NKXSxi000331; Thu, 23 Apr 2009 13:33:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIK00400M8DYX00@fe-sfbay-09.sun.com>; Thu, 23 Apr 2009 13:33:28 -0700 (PDT) Received: from [10.6.93.21] ([unknown] [10.6.93.21]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIK00747MFRTJ00@fe-sfbay-09.sun.com>; Thu, 23 Apr 2009 13:33:28 -0700 (PDT) Date: Thu, 23 Apr 2009 13:28:44 -0700 From: Erwin T Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> Sender: Erwin.Tsaur@sun.com To: Gary Winiger Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Reply-to: Erwin.Tsaur@sun.com Message-id: <49F0CF7C.50209@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 3103 On 04/23/09 11:26, Gary Winiger wrote: >>>> My recollection from 2005/232 was there was a discussion >>>> about non-standard install places. How was that resolved? >>>> >>>> I wasn't part of that discussion back then. Not sure what that would be about. >>>> >>>> >>> As the project is largely relying on that case with was about >>> an unbundled integration, it seems to me appropriate for the >>> project team to review the basis of this case and ensure that >>> the issues that were raised there are resolved now. >>> Saying something is not shipped with the WOS, but as an unbundled >>> with a limited set of users leads to different packaging and >>> installation that something shipping with the WOS. Since a >>> patch binding has been requested, the WOS in this case is >>> S10. >>> >>> >> Yes good point. There is another discussion going on about this whole >> packaging issue. It is definitely being scrutinized as the requesters >> for this tool all have their own requirements and such. >> > > If this is still being discussed, isn't the case premature? > Shouldn't this case be in waiting need spec until all relevant > peripheral discussions have completed? > > no.. packaging issues are separate and there are many ways to do this. As long as it is OK to for pcitool to be released in some sort of package or bundled somehow etc.. then we are set. Unless there are objections for this userland tool to be bundled somehow, I don't see how this can be an issue. >>>>> Risks and Assumptions: >>>>> PCITool allows privileged users to remap interrupt-CPU bindings >>>>> >>>>> >>>> What's a "privileged user"? What Rights Profile will pcitool >>>> be in? Again my recollection from 2005/232 is that "all" >>>> privileges is required. Is that still the case? Is there >>>> also some specific userID that's necessary >>>> >>>> Same rights nothing has changed, except some documentation. >>>> >>>> >>> Again there was a discussion of privileges that didn't >>> seem to converge. From the man page, I could read that >>> the only privilege needed is sys_res_config. 2005/233 >>> seemed to imply privs=all. This case materials doesn't >>> define how, now that pcitool will be provided as part of >>> the WOS, the sys_res_config privilege is granted to >>> pcitool. Specifically, what Rights Profile and is sys_res_config >>> the only privilege granted? Are there any uid requirements? >>> >>> >> The privileges really refer to the ioctls which this package has nothing >> to do with. We are only dealing with the userland binary. >> > > Ok, the privileges refer to the ioctls. I presume the userland > binary calls the ioctls. Is the only privilege the userland > binary requires sys_res_config? How does the userland binary > gain this or any other privileges? > I do not think this is relevant. That's like asking how does "cat" or "rm" gain this or any other privileges to read a file. A user can write a perl script to do the same thing. > Gary.. > From Erwin.Tsaur@sun.com Thu Apr 23 13:52:28 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3NKqRNZ025758 for ; Thu, 23 Apr 2009 13:52:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3NKqHTQ028356; Fri, 24 Apr 2009 04:52:26 +0800 (SGT) 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 <0KIK00B0BNBCLK00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Apr 2009 13:52:24 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIK00HBLNBCB780@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Apr 2009 13:52:24 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3NKqOFC019701; Thu, 23 Apr 2009 13:52:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIK00L00MTL4K00@fe-sfbay-09.sun.com>; Thu, 23 Apr 2009 13:52:24 -0700 (PDT) Received: from [10.6.93.21] ([unknown] [10.6.93.21]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIK0079HNAXTJ10@fe-sfbay-09.sun.com>; Thu, 23 Apr 2009 13:52:15 -0700 (PDT) Date: Thu, 23 Apr 2009 13:47:26 -0700 From: Erwin T Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49F0CF7C.50209@sun.com> Sender: Erwin.Tsaur@sun.com To: Erwin.Tsaur@sun.com Cc: Gary Winiger , Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Reply-to: Erwin.Tsaur@sun.com Message-id: <49F0D3DE.9000108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> <49F0CF7C.50209@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 3481 On 04/23/09 13:28, Erwin T Tsaur wrote: > On 04/23/09 11:26, Gary Winiger wrote: >>>>> My recollection from 2005/232 was there was a discussion >>>>> about non-standard install places. How was that resolved? >>>>> >>>>> I wasn't part of that discussion back then. Not sure what that >>>>> would be about. >>>>> >>>> As the project is largely relying on that case with was about >>>> an unbundled integration, it seems to me appropriate for the >>>> project team to review the basis of this case and ensure that >>>> the issues that were raised there are resolved now. >>>> Saying something is not shipped with the WOS, but as an unbundled >>>> with a limited set of users leads to different packaging and >>>> installation that something shipping with the WOS. Since a >>>> patch binding has been requested, the WOS in this case is >>>> S10. >>>> >>> Yes good point. There is another discussion going on about this >>> whole packaging issue. It is definitely being scrutinized as the >>> requesters for this tool all have their own requirements and such. >>> >> >> If this is still being discussed, isn't the case premature? >> Shouldn't this case be in waiting need spec until all relevant >> peripheral discussions have completed? >> >> > no.. packaging issues are separate and there are many ways to do this. > As long as it is OK to for pcitool to be released in some sort of > package or bundled somehow etc.. then we are set. > > Unless there are objections for this userland tool to be bundled > somehow, I don't see how this can be an issue. >>>>>> Risks and Assumptions: >>>>>> PCITool allows privileged users to remap interrupt-CPU bindings >>>>>> >>>>> What's a "privileged user"? What Rights Profile will pcitool >>>>> be in? Again my recollection from 2005/232 is that "all" >>>>> privileges is required. Is that still the case? Is there >>>>> also some specific userID that's necessary >>>>> >>>>> Same rights nothing has changed, except some documentation. >>>>> >>>> Again there was a discussion of privileges that didn't >>>> seem to converge. From the man page, I could read that >>>> the only privilege needed is sys_res_config. 2005/233 >>>> seemed to imply privs=all. This case materials doesn't >>>> define how, now that pcitool will be provided as part of >>>> the WOS, the sys_res_config privilege is granted to >>>> pcitool. Specifically, what Rights Profile and is sys_res_config >>>> the only privilege granted? Are there any uid requirements? >>>> >>> The privileges really refer to the ioctls which this package has >>> nothing to do with. We are only dealing with the userland binary. >>> >> >> Ok, the privileges refer to the ioctls. I presume the userland >> binary calls the ioctls. Is the only privilege the userland >> binary requires sys_res_config? How does the userland binary >> gain this or any other privileges? >> > I do not think this is relevant. That's like asking how does "cat" or > "rm" gain this or any other privileges to read a file. > > A user can write a perl script to do the same thing. btw.. like in the 2005/233 case, yes you have to be root to run pcitool or su to root. PCITool is not requiring anything of the extra defined privilege sets that root doesn't already have. >> Gary.. >> > From darren.moffat@sun.com Fri Apr 24 02:25:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3O9PYCB027292 for ; Fri, 24 Apr 2009 02:25:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3O9PWOL029237; Fri, 24 Apr 2009 10:25:34 +0100 (BST) 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 <0KIL00B07M6KWP00@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 03:25:32 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIL002WGM6JMU70@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 03:25:32 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3O9PV2W026685; Fri, 24 Apr 2009 09:25:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIL00500L6OZ100@fe-emea-09.sun.com>; Fri, 24 Apr 2009 10:25:31 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIL00HDGM6COU60@fe-emea-09.sun.com>; Fri, 24 Apr 2009 10:25:26 +0100 (BST) Date: Fri, 24 Apr 2009 10:25:25 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49F0CF7C.50209@sun.com> Sender: darren.moffat@sun.com To: Erwin.Tsaur@sun.com Cc: Gary Winiger , Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49F18585.9070000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> <49F0CF7C.50209@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 2085 Erwin T Tsaur wrote: > On 04/23/09 11:26, Gary Winiger wrote: >>>>> My recollection from 2005/232 was there was a discussion >>>>> about non-standard install places. How was that resolved? >>>>> >>>>> I wasn't part of that discussion back then. Not sure what that >>>>> would be about. >>>>> >>>> As the project is largely relying on that case with was about >>>> an unbundled integration, it seems to me appropriate for the >>>> project team to review the basis of this case and ensure that >>>> the issues that were raised there are resolved now. >>>> Saying something is not shipped with the WOS, but as an unbundled >>>> with a limited set of users leads to different packaging and >>>> installation that something shipping with the WOS. Since a >>>> patch binding has been requested, the WOS in this case is >>>> S10. >>>> >>> Yes good point. There is another discussion going on about this >>> whole packaging issue. It is definitely being scrutinized as the >>> requesters for this tool all have their own requirements and such. >>> >> >> If this is still being discussed, isn't the case premature? >> Shouldn't this case be in waiting need spec until all relevant >> peripheral discussions have completed? >> >> > no.. packaging issues are separate and there are many ways to do this. > As long as it is OK to for pcitool to be released in some sort of > package or bundled somehow etc.. then we are set. Not it is not separate it is very much part of the architecture review. Particularly given that where something is installed and how it is packaged (ie does it need a root and usr package) is dependent on wither or not it is bundled into the WOS or an unbundled separate download. The names of the packages are interfaces and should be included in the ARC case expect where it is obvious (eg a case adding a new API to libc it is obvious what package that is in, but a case adding a new cli and/or daemon or library needs to declare the packaging). -- Darren J Moffat From Erwin.Tsaur@Sun.COM Fri Apr 24 09:44:57 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OGiubO026477 for ; Fri, 24 Apr 2009 09:44:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OGit9k000477; Sat, 25 Apr 2009 00:44:55 +0800 (SGT) 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 <0KIM0060H6IURT00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Apr 2009 09:44:54 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00HK96IUK270@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Apr 2009 09:44:54 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OGisOd023050; Fri, 24 Apr 2009 09:44:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00F0061B5400@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 09:44:54 -0700 (PDT) Received: from [129.150.16.45] ([unknown] [129.150.16.45]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00DR26IOZP40@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 09:44:49 -0700 (PDT) Date: Fri, 24 Apr 2009 09:44:43 -0700 From: Erwin Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49F18585.9070000@Sun.COM> Sender: Erwin.Tsaur@Sun.COM To: Darren J Moffat Cc: Gary Winiger , Alan.Slivensky@Sun.COM, PSARC-ext@Sun.COM, pci-core@Sun.COM Message-id: <49F1EC7B.5070004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> <49F0CF7C.50209@sun.com> <49F18585.9070000@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 2508 Darren J Moffat wrote: > Erwin T Tsaur wrote: >> On 04/23/09 11:26, Gary Winiger wrote: >>>>>> My recollection from 2005/232 was there was a discussion >>>>>> about non-standard install places. How was that resolved? >>>>>> >>>>>> I wasn't part of that discussion back then. Not sure what that >>>>>> would be about. >>>>>> >>>>> As the project is largely relying on that case with was about >>>>> an unbundled integration, it seems to me appropriate for the >>>>> project team to review the basis of this case and ensure that >>>>> the issues that were raised there are resolved now. >>>>> Saying something is not shipped with the WOS, but as an unbundled >>>>> with a limited set of users leads to different packaging and >>>>> installation that something shipping with the WOS. Since a >>>>> patch binding has been requested, the WOS in this case is >>>>> S10. >>>>> >>>> Yes good point. There is another discussion going on about this >>>> whole packaging issue. It is definitely being scrutinized as the >>>> requesters for this tool all have their own requirements and such. >>>> >>> >>> If this is still being discussed, isn't the case premature? >>> Shouldn't this case be in waiting need spec until all relevant >>> peripheral discussions have completed? >>> >>> >> no.. packaging issues are separate and there are many ways to do this. >> As long as it is OK to for pcitool to be released in some sort of >> package or bundled somehow etc.. then we are set. > > Not it is not separate it is very much part of the architecture review. > > Particularly given that where something is installed and how it is > packaged (ie does it need a root and usr package) is dependent on > wither or not it is bundled into the WOS or an unbundled separate > download. > > The names of the packages are interfaces and should be included in the > ARC case expect where it is obvious (eg a case adding a new API to > libc it is obvious what package that is in, but a case adding a new > cli and/or daemon or library needs to declare the packaging). ok.. so working with the pkgteam and the requesters (SAE/PAE) of this tool, it, SUNWio-tools, is going to be in SUNWCXall, SUNWCall, and SUNWCprog. It does have dependencies on root and user packages like cakr and csu. But also to satisfy other requirements and time line, it'll also be an unbundled separate download via an SRU. > > > -- > Darren J Moffat From Peter.Dennis@sun.com Fri Apr 24 10:00:04 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 n3OH04AW027148 for ; Fri, 24 Apr 2009 10:00:04 -0700 (PDT) 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.2) with ESMTP id n3OH03Um053742; Fri, 24 Apr 2009 11:00:04 -0600 (MDT) 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 <0KIM00B05780BQ00@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 11:00:00 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM0091H77ZM510@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 11:00:00 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OGxx7r026070; Fri, 24 Apr 2009 16:59:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM0040075N4O00@fe-emea-10.sun.com>; Fri, 24 Apr 2009 17:59:59 +0100 (BST) Received: from [129.156.173.66] ([unknown] [129.156.173.66]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00JTW77T1930@fe-emea-10.sun.com>; Fri, 24 Apr 2009 17:59:53 +0100 (BST) Date: Fri, 24 Apr 2009 17:59:53 +0100 From: Peter Dennis - Sustaining Engineer Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49F1EC7B.5070004@sun.com> Sender: Peter.Dennis@sun.com To: Erwin Tsaur Cc: Darren J Moffat , Gary Winiger , Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49F1F009.9040502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> <49F0CF7C.50209@sun.com> <49F18585.9070000@Sun.COM> <49F1EC7B.5070004@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 267 > But also to satisfy other requirements and time line, it'll also be an > unbundled separate download via an SRU. Just for the record here SRU == Support Repository Update which is the vehicle for delivering fixes to the supported releases of OpenSolaris. Pete From Erwin.Tsaur@sun.com Thu Apr 30 11:26:10 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 n3UIQ9Ue020193 for ; Thu, 30 Apr 2009 11:26:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3UIQ89B007487; Thu, 30 Apr 2009 11:26:09 -0700 (PDT) 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 <0KIX00G0PF7LYN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 11:26:09 -0700 (PDT) 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 <0KIX0034JF7KVQA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 11:26:08 -0700 (PDT) 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 n3UIQ8W9029693; Thu, 30 Apr 2009 11:26:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIX00D00EGZ5000@fe-sfbay-10.sun.com>; Thu, 30 Apr 2009 11:26:08 -0700 (PDT) Received: from [10.6.93.21] ([unknown] [10.6.93.21]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIX00HCDF7H7GA0@fe-sfbay-10.sun.com>; Thu, 30 Apr 2009 11:26:05 -0700 (PDT) Date: Thu, 30 Apr 2009 11:21:16 -0700 From: Erwin T Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <49F1F009.9040502@sun.com> Sender: Erwin.Tsaur@sun.com Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Reply-to: Erwin.Tsaur@sun.com Message-id: <49F9EC1C.1040906@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Y+p2hT7Pwl6GA0J9j4CTAg)" X-PMX-Version: 5.4.1.325704 References: <200904231826.n3NIQ4PF027846@sac.sfbay.sun.com> <49F0CF7C.50209@sun.com> <49F18585.9070000@Sun.COM> <49F1EC7B.5070004@sun.com> <49F1F009.9040502@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 7891 This is a multi-part message in MIME format. --Boundary_(ID_Y+p2hT7Pwl6GA0J9j4CTAg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT After discussing with Gary Winiger I am amending the PSARC case to include more details about security. Excerpt from the man page. Required privileges The user must have all privileges in order to access inter- rupt information. A regular user can access interrupt information when su(1M) to root or granted the "Maintenance and Repair" rights profile in the user_attr file. See user_attr(4) and rbac(5). Below is summary of the discussion with Gary. From project team: I had a discussion with the RE and here is what I understand: 1) delivery mechanism/packaging/installation path Answer on a) mechanism, b) packaging, and c) installation path: a) SRU, Developer cluster, Entire Distribution cluster, Entire+OEM cluster b) SUNWio-tools c) /usr/sbin/pcitool From Gary Winiger: /usr/sbin/pcitool seems fine to me. From project team: 2) necessary context to run the command and how that context is provided to the administrator through Solaris mechanisms -- in particular Rights Profiles Answer: The ioctl code in kernel has the following: /* Require full privileges. */ if (secpolicy_kmdb(credp)) rv = EPERM; else rv = pxtool_dev_reg_ops(dip, (void *)arg, cmd, mode); That means any user with profile rights of "Maintenance and Repair" would be able to pfexec it. And I just tried it on my own system. From Gary Winiger: Is the project team now saying that privs=all is required? Some justification usually comes along with such a requirement. One such justification could be that the use of pcitool could lead to privilege escalation, thus privs=all is required. Along with such a statement would come an explaination as to how it could lead to privilege escalation. From project team: Yes privs=all is required because using this tool can change the low level hardware behavior including causing system memory to be silently overwritten, thus privilege escalation. From Gary Winiger: Is the project team saying that /usr/sbin/pcitool is already contained in the "Maintenance and Repair" Rights Profile? My snv_104 system doesn't seem to contain it. From project team: It is currently not in the "Maintenance and Repair" Rights Profile and we don't plan to ship it with it configured in it. Do you recommend otherwise? From Gary Winiger: Manintenance and Repair seems like an appropriate Rights Profile. The specification can state that the will be adding /usr/sbin/pcitool to the existing Maintenance and Repair Rights Profile with attributes of --- and you state the attributes. See http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ for how to add to the RBAC databases. --Boundary_(ID_Y+p2hT7Pwl6GA0J9j4CTAg) Content-type: text/plain; name=pcitool.manpage Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pcitool.manpage Maintenance Commands pcitool(1M) NAME pcitool - interrupt routing tool SYNOPSIS /usr/sbin/pcitool PCI_nexus_node -i ino=ino [ -r [ -c ] | -w cpu=CPU [ -g ] ] [ -v ] [ -q ] /usr/sbin/pcitool [ -h ] DESCRIPTION PCItool is a low-level tool which provides a facility for getting and setting interrupt routing information. Interrupt Routing The pcitool -i command displays device and CPU routing information for all inos on a given nexus, and allows rerouting of a given ino or ino group to a specific CPU. Required privileges The user must have all privileges in order to access inter- rupt information. A regular user can access interrupt information when su(1M) to root or granted the "Maintenance and Repair" rights profile in the user_attr file. See user_attr(4) and rbac(5). Commandline options -r [ -c ] Display device and CPU routing information for inos on a given nexus. The device path and instance number of each device for each displayed ino will be shown. On some plat- forms (e.g. Fire) interrupts dedicated to the root complex are indicated with "(Internal)" appended to their pathname. Dump interrupt controller information with -c. If neither -r nor -w are provided on the commandline, -r is assumed. The command for showing all inos on /pci@8,700000 is: # pcitool /pci@8,700000 -i The command for showing ino 0x23 on the same root nexus, along with sample output, is: # pcitool /pci@8,700000 -i ino=23 ino 23 on ctlr 0 mapped to cpu 0 Device: /pci@8,700000/ebus@5/i2c@1,30 Driver: pcf8584, instance 1 Device: /pci@8,700000/ebus@5/i2c@1,2e Driver: pcf8584, instance 0 -w cpu=hex_CPU [ -g ] Route the given ino to the given CPU. Display the new and original routing information. The ino must be specified. Successful rerouting ino 23 above from cpu 0 to cpu 1 gives the following output: # pcitool /pci@8,700000 -i ino=23 -w cpu=1 Interrupts on ino 23 reassigned: Old cpu:0, New cpu:1 On some platforms (such as X86) multiple MSI interrupts of a single function need to be rerouted together. Use -g to do this. -g works only on supported platforms and only for groups of MSI interrupts. (A "group" of 1 is accepted.) When -g is used, the vector provided must be the lowest- numbered vector of the group. The size of the group is determined internally. Successful rerouting a group of inos starting at 60 from cpu 0 to cpu 1 gives the following output: # pcitool /pci@0,0 -i ino=60 -w cpu=1 -g Interrupts on ino group starting at ino 60 reassigned: Old cpu:0, New cpu:1 -v Verbose output. -q No errors reported as messages. Unix error status still returned by program, however. EXIT STATUS The following error statuses are returned to the shell: 0 No error EINVAL Out-of-range, misaligned or other- wise invalid argument has been passed in. ETIME Timeout waiting for pending inter- rupt to settle before changing interrupts to a new CPU. EIO An IO error occurred. FILES /usr/sbin/pcitool ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |______________________|__________________________________| | Architecture | PCI-based systems | |______________________|__________________________________| | Availability | SUNWio-tools | |______________________|__________________________________| | Interface Stability | Volatile | |______________________|__________________________________| SEE ALSO pci(4), su(1M), user_attr(4), rbac(5) NOTES All values are entered in hex. Not all commands are applicable to all platforms. Root access is required to execute all commands in this tool. REFERENCES PCI specification (available from www.pcisig.org) --Boundary_(ID_Y+p2hT7Pwl6GA0J9j4CTAg)-- From gww@sac.sfbay.sun.com Fri May 1 10:13:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41HDoZB005719 for ; Fri, 1 May 2009 10:13:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41HDZFn019013; Fri, 1 May 2009 18:13:49 +0100 (BST) 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 <0KIZ00L136IZ5600@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 11:13:47 -0600 (MDT) 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 <0KIZ008ZS6IYFD70@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 11:13:46 -0600 (MDT) 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.2) with ESMTP id n41HDkO6035312; Fri, 01 May 2009 10:13:46 -0700 (PDT) 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 n41HDiAN005716; Fri, 01 May 2009 10:13:44 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n41HDhc6005715; Fri, 01 May 2009 10:13:43 -0700 (PDT) Date: Fri, 01 May 2009 10:13:43 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: Erwin.Tsaur@sun.com Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <200905011713.n41HDhc6005715@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2152 > After discussing with Gary Winiger I am amending the PSARC case to > include more details about security. I'm probably being overly picky here. In my offline discussions there seemed to be confusion about the (architectural) details. Including that I'm not the only one on the committee. > From project team: > It is currently not in the "Maintenance and Repair" Rights Profile and > we don't plan to ship it with it configured in it. Do you recommend > otherwise? > > From Gary Winiger: > Manintenance and Repair seems like an appropriate Rights Profile. > The specification can state that the will be adding /usr/sbin/pcitool > to the existing Maintenance and Repair Rights Profile with attributes > of --- and you state the attributes. I've missed seeing the specification that pcitool will be added to Maintenane and Repair and with what attributes. > See > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > for how to add to the RBAC databases. I'm happy to coach how to deliver into the RBAC databases should the best practice not be sufficient for the project team. > Maintenance Commands pcitool(1M) > > NAME > pcitool - interrupt routing tool > > SYNOPSIS > /usr/sbin/pcitool PCI_nexus_node -i ino=ino [ -r [ -c ] | -w > cpu=CPU [ -g ] ] [ -v ] [ -q ] > > /usr/sbin/pcitool [ -h ] > Required privileges > > The user must have all privileges in order to access inter- > rupt information. A regular user can access interrupt > information when su(1M) to root or granted the "Maintenance > and Repair" rights profile in the user_attr file. See > user_attr(4) and rbac(5). > SEE ALSO > pci(4), su(1M), user_attr(4), rbac(5) > > NOTES > Root access is required to execute all commands in this > tool. Probably a nit. The preceeding gives me pause over what the specification for Rights Profiles inclusion really is. Should this note just be eliminated, or is there some hard requirement for euid==ruid==0 which cannot be met otherwise. Gary.. From Erwin.Tsaur@sun.com Fri May 1 11:09:56 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41I9tQC008145 for ; Fri, 1 May 2009 11:09:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n41I9S1q026033; Sat, 2 May 2009 02:09:54 +0800 (SGT) 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 <0KIZ0030994FPV00@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 12:09:51 -0600 (MDT) 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 <0KIZ008Q994FFQD0@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 12:09:51 -0600 (MDT) 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 n41I9oWx027662; Fri, 01 May 2009 11:09:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIZ00L008W2B900@fe-sfbay-10.sun.com>; Fri, 01 May 2009 11:09:50 -0700 (PDT) Received: from [129.150.20.190] ([unknown] [129.150.20.190]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIZ00F9K94DV0B0@fe-sfbay-10.sun.com>; Fri, 01 May 2009 11:09:50 -0700 (PDT) Date: Fri, 01 May 2009 11:09:33 -0700 From: Erwin Tsaur Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <200905011713.n41HDhc6005715@sac.sfbay.sun.com> Sender: Erwin.Tsaur@sun.com To: Gary Winiger Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49FB3ADD.6050009@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_bQrr7VlwDvSZVr1sPIfC+g)" X-PMX-Version: 5.4.1.325704 References: <200905011713.n41HDhc6005715@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 7705 This is a multi-part message in MIME format. --Boundary_(ID_bQrr7VlwDvSZVr1sPIfC+g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: >> After discussing with Gary Winiger I am amending the PSARC case to >> include more details about security. >> > > I'm probably being overly picky here. In my offline discussions > there seemed to be confusion about the (architectural) details. > Including that I'm not the only one on the committee. > > >> From project team: >> It is currently not in the "Maintenance and Repair" Rights Profile and >> we don't plan to ship it with it configured in it. Do you recommend >> otherwise? >> >> From Gary Winiger: >> Manintenance and Repair seems like an appropriate Rights Profile. >> The specification can state that the will be adding /usr/sbin/pcitool >> to the existing Maintenance and Repair Rights Profile with attributes >> of --- and you state the attributes. >> > > I've missed seeing the specification that pcitool will be > added to Maintenane and Repair and with what attributes. > > >> See >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ >> for how to add to the RBAC databases. >> > > I'm happy to coach how to deliver into the RBAC databases should > the best practice not be sufficient for the project team. > I've read the link above, and I believe I just need to... (please correct if wrong) add the line: Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all to usr/src/lib/libsecdb/exec_attr.txt "Maintenance and Repair" is an existing Rights Profile. Sample of other commands in the same profile are mdb, coreadm, halt and reboot. > >> Maintenance Commands pcitool(1M) >> >> NAME >> pcitool - interrupt routing tool >> >> SYNOPSIS >> /usr/sbin/pcitool PCI_nexus_node -i ino=ino [ -r [ -c ] | -w >> cpu=CPU [ -g ] ] [ -v ] [ -q ] >> >> /usr/sbin/pcitool [ -h ] >> > > >> Required privileges >> >> The user must have all privileges in order to access inter- >> rupt information. A regular user can access interrupt >> information when su(1M) to root or granted the "Maintenance >> and Repair" rights profile in the user_attr file. See >> user_attr(4) and rbac(5). >> > > >> SEE ALSO >> pci(4), su(1M), user_attr(4), rbac(5) >> >> NOTES >> > > >> Root access is required to execute all commands in this >> tool. >> > > Probably a nit. The preceeding gives me pause over what the > specification for Rights Profiles inclusion really is. > Should this note just be eliminated, or is there some hard > requirement for euid==ruid==0 which cannot be met otherwise. > That's right, something left over from the old PSARC case, which I removed now. Updated manpage included > Gary.. > --Boundary_(ID_bQrr7VlwDvSZVr1sPIfC+g) Content-type: text/plain; name=pcitool.manpage Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pcitool.manpage Maintenance Commands pcitool(1M) NAME pcitool - interrupt routing tool SYNOPSIS /usr/sbin/pcitool PCI_nexus_node -i ino=ino [ -r [ -c ] | -w cpu=CPU [ -g ] ] [ -v ] [ -q ] /usr/sbin/pcitool [ -h ] DESCRIPTION PCItool is a low-level tool which provides a facility for getting and setting interrupt routing information. Interrupt Routing The pcitool -i command displays device and CPU routing information for all inos on a given nexus, and allows rerouting of a given ino or ino group to a specific CPU. Required privileges The user must have all privileges in order to access inter- rupt information. A regular user can access interrupt information when su(1M) to root or granted the "Maintenance and Repair" rights profile in the user_attr file. See user_attr(4) and rbac(5). Commandline options -r [ -c ] Display device and CPU routing information for inos on a given nexus. The device path and instance number of each device for each displayed ino will be shown. On some plat- forms (e.g. Fire) interrupts dedicated to the root complex are indicated with "(Internal)" appended to their pathname. Dump interrupt controller information with -c. If neither -r nor -w are provided on the commandline, -r is assumed. The command for showing all inos on /pci@8,700000 is: # pcitool /pci@8,700000 -i The command for showing ino 0x23 on the same root nexus, along with sample output, is: # pcitool /pci@8,700000 -i ino=23 ino 23 on ctlr 0 mapped to cpu 0 Device: /pci@8,700000/ebus@5/i2c@1,30 Driver: pcf8584, instance 1 Device: /pci@8,700000/ebus@5/i2c@1,2e Driver: pcf8584, instance 0 -w cpu=hex_CPU [ -g ] Route the given ino to the given CPU. Display the new and original routing information. The ino must be specified. Successful rerouting ino 23 above from cpu 0 to cpu 1 gives the following output: # pcitool /pci@8,700000 -i ino=23 -w cpu=1 Interrupts on ino 23 reassigned: Old cpu:0, New cpu:1 On some platforms (such as X86) multiple MSI interrupts of a single function need to be rerouted together. Use -g to do this. -g works only on supported platforms and only for groups of MSI interrupts. (A "group" of 1 is accepted.) When -g is used, the vector provided must be the lowest- numbered vector of the group. The size of the group is determined internally. Successful rerouting a group of inos starting at 60 from cpu 0 to cpu 1 gives the following output: # pcitool /pci@0,0 -i ino=60 -w cpu=1 -g Interrupts on ino group starting at ino 60 reassigned: Old cpu:0, New cpu:1 -v Verbose output. -q No errors reported as messages. Unix error status still returned by program, however. EXIT STATUS The following error statuses are returned to the shell: 0 No error EINVAL Out-of-range, misaligned or other- wise invalid argument has been passed in. ETIME Timeout waiting for pending inter- rupt to settle before changing interrupts to a new CPU. EIO An IO error occurred. FILES /usr/sbin/pcitool ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |______________________|__________________________________| | Architecture | PCI-based systems | |______________________|__________________________________| | Availability | SUNWio-tools | |______________________|__________________________________| | Interface Stability | Volatile | |______________________|__________________________________| SEE ALSO pci(4), su(1M), user_attr(4), rbac(5) NOTES All values are entered in hex. Not all commands are applicable to all platforms. REFERENCES PCI specification (available from www.pcisig.org) --Boundary_(ID_bQrr7VlwDvSZVr1sPIfC+g)-- From gww@eng.sun.com Fri May 1 11:32: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 n41IWFxE009456 for ; Fri, 1 May 2009 11:32:15 -0700 (PDT) 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.2) with ESMTP id n41IWD7Y005648; Fri, 1 May 2009 12:32:15 -0600 (MDT) 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 <0KIZ0060BA5P0W00@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 12:32:13 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIZ008O4A5PFRD0@brm-avmta-1.central.sun.com>; Fri, 01 May 2009 12:32:13 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41IWC1x033647; Fri, 01 May 2009 11:32:12 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n41IVOVZ016622; Fri, 01 May 2009 11:31:24 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n41IVOTa016621; Fri, 01 May 2009 11:31:24 -0700 (PDT) Date: Fri, 01 May 2009 11:31:24 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: gww@sac.sfbay.sun.com, Erwin.Tsaur@sun.com Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <200905011831.n41IVOTa016621@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 961 > > I've missed seeing the specification that pcitool will be > > added to Maintenane and Repair and with what attributes. > > > > > >> See > >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > >> for how to add to the RBAC databases. > >> > > > > I'm happy to coach how to deliver into the RBAC databases should > > the best practice not be sufficient for the project team. > > > I've read the link above, and I believe I just need to... (please > correct if wrong) add the line: > > Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all > > to usr/src/lib/libsecdb/exec_attr.txt This is correct and says implicitly that there is no special uid requirement. If you need assistance in the delivery mechanism, let me know. > That's right, something left over from the old PSARC case, which I > removed now. Updated manpage included My issues are all addressed. I'll give it a +1. Gary.. From gww@eng.sun.com Fri May 1 11:36:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41IaOqU009809 for ; Fri, 1 May 2009 11:36:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n41IaBH9012021; Sat, 2 May 2009 02:36:24 +0800 (SGT) 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 <0KIZ0010VACMPD00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 May 2009 11:36:22 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIZ00CDWACMPLC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 May 2009 11:36:22 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41IaLxb036939; Fri, 01 May 2009 11:36:21 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n41IZXK1016632; Fri, 01 May 2009 11:35:33 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n41IZXn8016631; Fri, 01 May 2009 11:35:33 -0700 (PDT) Date: Fri, 01 May 2009 11:35:33 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2009/215 PCITool Public Interrupts To: gww@sac.sfbay.sun.com, Erwin.Tsaur@sun.com, gww@eng.sun.com Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <200905011835.n41IZXn8016631@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1337 > From gww@eng.sun.com Fri May 1 11:31:26 2009 > Date: Fri, 1 May 2009 11:31:24 -0700 (PDT) > From: Gary Winiger > To: gww@sac.sfbay.sun.com, Erwin.Tsaur@sun.com > Subject: Re: PSARC 2009/215 PCITool Public Interrupts > Cc: Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com > > > > I've missed seeing the specification that pcitool will be > > > added to Maintenane and Repair and with what attributes. > > > > > > > > >> See > > >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > > >> for how to add to the RBAC databases. > > >> > > > > > > I'm happy to coach how to deliver into the RBAC databases should > > > the best practice not be sufficient for the project team. > > > > > I've read the link above, and I believe I just need to... (please > > correct if wrong) add the line: > > > > Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all > > > > to usr/src/lib/libsecdb/exec_attr.txt > > This is correct and says implicitly that there is no special > uid requirement. > If you need assistance in the delivery mechanism, let me know. My comment here presumed this is not part of ON. If it is part of ON packaging is already there. We can talk off line if we need to. Send me private email and we'll arrange a time. Gary.. From gdamore@sun.com Fri May 1 11:42:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41IgH8q009939 for ; Fri, 1 May 2009 11:42:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41IgFRQ019066; Fri, 1 May 2009 19:42:16 +0100 (BST) 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 <0KIZ00109AMFRQ00@nwk-avmta-2.sfbay.sun.com>; Fri, 01 May 2009 11:42:15 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIZ00DRXAME20C0@nwk-avmta-2.sfbay.sun.com>; Fri, 01 May 2009 11:42:15 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n41IgESe001305; Fri, 01 May 2009 11:42:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIZ00A00A7TBJ00@fe-sfbay-09.sun.com>; Fri, 01 May 2009 11:42:14 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIZ001QBAMDCU60@fe-sfbay-09.sun.com>; Fri, 01 May 2009 11:42:14 -0700 (PDT) Date: Fri, 01 May 2009 11:42:12 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <200905011831.n41IVOTa016621@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: gww@sac.sfbay.sun.com, Erwin.Tsaur@sun.com, Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49FB4284.4020605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905011831.n41IVOTa016621@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1126 Gary Winiger wrote: >>> I've missed seeing the specification that pcitool will be >>> added to Maintenane and Repair and with what attributes. >>> >>> >>> >>>> See >>>> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ >>>> for how to add to the RBAC databases. >>>> >>>> >>> I'm happy to coach how to deliver into the RBAC databases should >>> the best practice not be sufficient for the project team. >>> >>> >> I've read the link above, and I believe I just need to... (please >> correct if wrong) add the line: >> >> Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all >> >> to usr/src/lib/libsecdb/exec_attr.txt >> > > This is correct and says implicitly that there is no special > uid requirement. > If you need assistance in the delivery mechanism, let me know. > > >> That's right, something left over from the old PSARC case, which I >> removed now. Updated manpage included >> > > My issues are all addressed. I'll give it a +1. > > Gary.. > Thanks. I'll mark this case closed approved then. -- Garrett From gdamore@sun.com Fri May 1 15:16:51 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 n41MGoRr012355 for ; Fri, 1 May 2009 15:16:50 -0700 (PDT) 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.2) with ESMTP id n41MGhYw044023; Fri, 1 May 2009 16:16:49 -0600 (MDT) 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 <0KIZ00703KJ9F700@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 May 2009 15:16:21 -0700 (PDT) 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 <0KIZ007JVKJ9ZNC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 May 2009 15:16:21 -0700 (PDT) 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 n41MGL9g004825; Fri, 01 May 2009 15:16:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIZ00000KIHY600@fe-sfbay-10.sun.com>; Fri, 01 May 2009 15:16:21 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIZ00DSIKIZ2G30@fe-sfbay-10.sun.com>; Fri, 01 May 2009 15:16:12 -0700 (PDT) Date: Fri, 01 May 2009 15:16:11 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/215 PCITool Public Interrupts In-reply-to: <200905011831.n41IVOTa016621@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: gww@sac.sfbay.sun.com, Erwin.Tsaur@sun.com, Alan.Slivensky@sun.com, PSARC-ext@sun.com, pci-core@sun.com Message-id: <49FB74AB.6010408@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905011831.n41IVOTa016621@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 111 Okay, just to formally make sure it is recorded in an obvious manner: this case is approved. -- Garrett