From sacadmin Sun Feb 17 12:58:01 2008 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 m1HKw1Rj011617; Sun, 17 Feb 2008 12:58:01 -0800 (PST) Received: (from mws@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m1HKw17N011613; Sun, 17 Feb 2008 12:58:01 -0800 (PST) Date: Sun, 17 Feb 2008 12:58:01 -0800 (PST) From: Michael Shapiro Message-Id: <200802172058.m1HKw17N011613@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: sun4v /dev/bmc [PSARC/2008/119 FastTrack timeout 02/20/2008] Status: RO Content-Length: 553 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sun4v /dev/bmc 1.2. Name of Document Author/Supplier: Author: Kyoung Yun 1.3 Date of This Document: 17 February, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From mws@zion.sfbay.sun.com Sun Feb 17 13:08:34 2008 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 m1HL8YBI011735 for ; Sun, 17 Feb 2008 13:08:34 -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.2) with ESMTP id m1HL8X6G019816; Sun, 17 Feb 2008 14:08:33 -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 <0JWE00C01IQ9RP00@brm-avmta-1.central.sun.com>; Sun, 17 Feb 2008 14:08:33 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWE007N0IQ8BOA0@brm-avmta-1.central.sun.com>; Sun, 17 Feb 2008 14:08:32 -0700 (MST) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1HL8WxL132917; Sun, 17 Feb 2008 21:08:32 +0000 (GMT) Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1HL8V8L132916; Sun, 17 Feb 2008 13:08:31 -0800 (PST) Date: Sun, 17 Feb 2008 13:08:31 -0800 From: Mike Shapiro Subject: PSARC 2008/119 sun4v /dev/bmc To: psarc-ext@sun.com Cc: kyoung.yun@sun.com, mws@sun.com Message-id: <20080217210831.GA132867@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 11541 I'm sponsoring the follow fast-track for Kyoung Yun. It has binding for a Micro, with timer set for Friday 2/20. Quick background summary from me: on our x64 platforms, we support an OS->SP IPMI channel via a hardware KCS interface which permits Solaris to send IPMI queries and commands directly to the SP. The software abstraction built on top of this interface is the /dev/bmc pseudo-driver, which currently exists only on x64 platforms. Its kernel/user interface is covered in existing ARC cases, and the payload data is the DMTF standard IPMI protocol. (The IPMI stack can also be accessed over a LAN using the SP's network interface.) On SPARC platforms, the KCS hardware is not present, but an IPMI stack is offered that can be accessed over the SP's external network interface. This case improves the commonality between x64 and SPARC, by adding a software- compatible /dev/bmc for sun4v that uses internal hypervisor channels instead of the missing KCS hardware. The result is that userland software that consumes /dev/bmc will now work transparently on sun4v platforms. For example, "ipmitool -I bmc " now just works unmodified. The material below is written as a one-pager but since this is all existing ARC'ed interfaces I felt this qualified for a fast-track. -Mike -- #pragma ident "@(#)onepager.txt 1.3 08/02/15 SMI" Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: /dev/bmc for sun4v 1.2. Name of Document Author/Supplier: Kyoung-Hwan Yun 1.3. Date of This Document: 02/15/08 1.3.1. Date this project was conceived: 01/28/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: SSG PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Jess Lawrendra 1.4.4. The name of your business unit: Netra System and Networking (NSN, SSG) 1.5. Email Aliases: 1.5.1. Responsible Manager: mehrdad.mojgani@sun.com 1.5.2. Responsible Engineer: kyoung.yun@sun.com 1.5.3. Marketing Manager: nathalie.nann@sun.com 1.5.4. Interest List: turgo-sw@sun.com turgo-eteam@sun.com turgo-ipmi@sun.com 2. Project Summary 2.1. Project Description: This project will provide the /dev/bmc driver for SPARC, interface-compatible with the /dev/bmc driver for x86. 2.2. Risks and Assumptions: - The primary consumer of this driver is the open source "ipmitool". - This project assumes that virtual channel and IPMI service task are provided by ILOM/vBSC. - The CLI support is leveraged from the "ipmitool" sunoem CLI feature, which has already been integrated for most Galaxy and Constellation platforms. 3. Business Summary 3.1. Problem Area: Many of our customers who use sun4v based Netra rack mount servers have no network or serial connection to the SP, but they still want to have full administrative access to the SP. This namely includes, but not limited to, the CLI support from the host to the SP, the ability to get/set sc variables, and the "ipmitool" support. The "ipmitool" support alone will open up the ways to support easily the other features (and others to come in the future) through IPMI. Currently, Solaris has ipmitool(1m) support with BMC, LAN and LAN+ interfaces. x86 or Galaxy systems typically use the KCS interface, but sun4v systems typically use LAN or LAN+ interface to send RMCP and RMCP+ packets, respectively. Because sun4v systems lack the support for the BMC interface, customers are required to change command-line usages between x86 and sun4v platforms. This creates inconvenience to customers due to lack of a uniform interface. It's important to know that many of our major customers are requesting support for aforementioned features without using networking due to security concerns. An "scadm"-like interface has been asked for for a while. In addition, customers would like to have access to the SP even when the password is lost or reset. The LAN and LAN+ interfaces cannot meet this requirement because they are session-based. 3.2. Market/Requester: The customers using sun4v based Netra rack mount servers. However, other sun4v based platforms will also benefit from this project. 3.3. Business Justification: - "ipmitool" (which is an open source) will not need any modifications by this project. - "ipmitool" support not using external networking was requested by customers. - Sessionless interface was requested by customers. - Interface compatibility can be provided by having support for the BMC interface on both x86 and SPARC. 3.4. Competitive Analysis: Sun's major competitors provide utilities which can completely customize the SP from the Solaris host. 3.5. Opportunity Window/Exposure: 3.6. How will you know when you are done?: - When related code changes are integrated into Solaris. - When the QE completes their tests. - When no outstanding P1/P2/P3 bug exists. 4. Technical Description: 4.1. Details: There are two submodules making up /dev/bmc on sun4v: the front-end, which exports the interfaces identical to those exported by /dev/bmc on x86; and the back-end, which actually sends and receives packets between the host and SP. The front-end implementation will be very similar to the one from x86, but the back-end implementation will diverge because, obviously, the communication will be done through the vldc driver. See Figure 1 for overall relationship of /dev/bmc and other components of the system. . ------------------- . | ipmitool/others | . ------------------- . | . | . ============ . ------------------ # /dev/bmc # . | IPMI ILOM task | ============ . ------------------ | . | | . | -------- virtual channel . -------- | vldc |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| vBSC | -------- . -------- . H O S T . S P Figure 1. 4.2. Bug/RFE Number(s): 6651404 Netra-T5220 needs ipmitool support through internal communication channel 4.3. In Scope: - This driver will support sun4v with ILOM only. 4.4. Out of Scope: - Non-sun4v will not be supported by this driver because of lack of vldc support. - System with ALOM will not be supported. 4.5. Interfaces: The project exports the following interfaces, which are the same for the x86 version: ___________________________________________________________________________ | Interfaces Exported | |____________________________|_________________|__________________________| | Interface | Classification | Comments | |____________________________|_________________|__________________________| | IOCTL_IPMI_INTERFACE_METHOD| Contract/Private| ioctl control function | | | | for determining messaging| | | | interface to use.* | | | | PSARC/2005/161 | | | | PSARC/2006/221 | | getmsg() / putmsg() | Contract/Private| See bmc_intf.h | | | | PSARC/2005/161 | | | | PSARC/2006/221 | | /platform/sun4v/kernel/drv/|||||||||||||||||||||||||||||||||||||||||||||| | bmc.conf | Contract/Private| bmc driver .conf file | | | | PSARC/2005/161 | | | | PSARC/2006/221 | | bmc | Contract/Private| bmc driver binary | | | | PSARC/2005/161 | | | | PSARC/2006/221 | |____________________________|_________________|__________________________| * This SPARC version does not support the "old" IOCTL_IPMI_KCS_ACTION, because it's KCS specific; ioctl calls for IOCTL_IPMI_KCS_ACTION will fall back to use putmsg()/getmsg() interfaces. The project imports the following interfaces, as does the x86 version: ___________________________________________________________________________ | Interfaces Imported | |____________________________|_________________|__________________________| | Interface | Classification | Comments | |____________________________|_________________|__________________________| | /usr/include/sys/stream.h | Consol./Private | DB_CRED() PSARC/2003/648 | |____________________________|_________________|__________________________| 4.6. Doc Impact: No existing documentation will be impacted. 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: No. 4.10. Packaging & Delivery: The bmc driver and its related files will be added to SUNWcakr.v. 4.11. Security Impact: This driver will follow the same security policy as /dev/bmc on x86. 4.12. Dependencies: - vldc driver interfaces. 5. Reference Documents: [1] "ipmitool" man page http://ipmitool.sourceforge.net/manpage.html [2] "ipmitool" CLI one-pager http://nsgtwiki.sfbay.sun.com/twiki/pub/Hotamale/IlomOnePagers/ipmitool_cli.txt [3] IPMI Specification http://developer.intel.com/design/servers/ipmi [4] 6605576 turgo needs internal ILOM interface to ipmitool [5] PSARC/2006/152 Logical Domain Channels Transport API [6] PSARC/2004/453 Intelligent Platform Management Interface - IPMI x86 [7] PSARC/2005/161 Extension of bmc/ipmitool interface [8] PSARC/2006/221 /dev/bmc interface upgrade 6. Resources and Schedule: 6.1. Projected Availability: Q2CY08 6.2. Cost of Effort: ~2 staff-months engineering 6.3. Cost of Capital Resources: N/A. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: N/A. 6.4.5. Is this a necessary project for OEM agreements: No. 6.4.6. Notes: 6.4.7. Target RTI Date/Release: ONNV: March 2008 ON10: April 2008 6.4.8. Target Code Design Review Date: February 2008 6.4.9. Update approval addition: No. 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 7. Prototype Availability: 7.1. Prototype Availability: A prototype is available now, waiting to be unit-tested with the SP counterpart. 7.2. Prototype Cost: N/A. From roland.mainz@nrubsig.org Sun Feb 17 18:46:28 2008 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 m1I2kRsR020705 for ; Sun, 17 Feb 2008 18:46:28 -0800 (PST) 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 m1I2kKQc017065; Mon, 18 Feb 2008 10:46:23 +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 <0JWE00I0VYD8J100@nwk-avmta-1.sfbay.Sun.COM>; Sun, 17 Feb 2008 18:46:20 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWE008RKYD71J30@nwk-avmta-1.sfbay.Sun.COM>; Sun, 17 Feb 2008 18:46:19 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1I2dEem014691; Mon, 18 Feb 2008 02:46:19 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay22i.sun.com with ESMTP id BT-MMP-283757; Mon, 18 Feb 2008 02:46:19 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms25es.sun.com with ESMTP id BT-MMP-2114288; Mon, 18 Feb 2008 02:46:19 +0000 (Z) Received: from mail-in-01.arcor-online.net ([151.189.21.41] [151.189.21.41]) by relay24i.sun.com with ESMTP id BT-MMP-8223514; Mon, 18 Feb 2008 02:46:18 +0000 (Z) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 2B7DC104306; Mon, 18 Feb 2008 03:46:18 +0100 (CET) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 1B8471B8E41; Mon, 18 Feb 2008 03:46:18 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-030-015.pools.arcor-ip.net [84.59.30.15]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id EF89136E864; Mon, 18 Feb 2008 03:46:17 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m1I2kFHM001287; Mon, 18 Feb 2008 03:46:16 +0100 (CET) Date: Mon, 18 Feb 2008 03:46:15 +0100 From: Roland Mainz Subject: Re: PSARC 2008/119 sun4v /dev/bmc Sender: gisburn@jupiterb48.nrubsig.org To: Mike Shapiro Cc: psarc-ext@sun.com, kyoung.yun@sun.com Message-id: <47B8F177.9EDEDD03@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/5855/Sun Feb 17 23:36:38 2008 on mail-in-02.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=-1.1/5.0, scanned in 0.108sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080217210831.GA132867@sun.com> Status: RO Content-Length: 526 Mike Shapiro wrote: [snip] > #pragma ident "@(#)onepager.txt 1.3 08/02/15 SMI" > Copyright 2008 Sun Microsystems > > XXX XXXXXXXXXXX/XXXXXXXXXXXX: Internal Use Only: Engineering Need-to-Know [snip] > 6.6. ARC Exposure: > > open Mhhh... "Proprietary/Confidential" vs. "open" ... how is this supposed to work ? :-) :-) :-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From mws@zion.sfbay.sun.com Sun Feb 17 22:01:33 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1I61Xi9024415 for ; Sun, 17 Feb 2008 22:01:33 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1I61VFo009129; Sun, 17 Feb 2008 22:01:32 -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 <0JWF00D0J7EJ4U00@brm-avmta-1.central.sun.com>; Sun, 17 Feb 2008 23:01:31 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWF00MZ57EH1IE0@brm-avmta-1.central.sun.com>; Sun, 17 Feb 2008 23:01:29 -0700 (MST) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1I5rx1d136046; Mon, 18 Feb 2008 05:53:59 +0000 (GMT) Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1I5rxOY136045; Sun, 17 Feb 2008 21:53:59 -0800 (PST) Date: Sun, 17 Feb 2008 21:53:58 -0800 From: Mike Shapiro Subject: Re: PSARC 2008/119 sun4v /dev/bmc In-reply-to: <47B8F177.9EDEDD03@nrubsig.org> To: Roland Mainz Cc: psarc-ext@sun.com, kyoung.yun@sun.com Message-id: <20080218055358.GA136041@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20080217210831.GA132867@sun.com> <47B8F177.9EDEDD03@nrubsig.org> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 599 On Mon, Feb 18, 2008 at 03:46:15AM +0100, Roland Mainz wrote: > Mike Shapiro wrote: > [snip] > > #pragma ident "@(#)onepager.txt 1.3 08/02/15 SMI" > > Copyright 2008 Sun Microsystems > > > > XXX XXXXXXXXXXX/XXXXXXXXXXXX: Internal Use Only: Engineering Need-to-Know > [snip] > > 6.6. ARC Exposure: > > > > open > > Mhhh... "Proprietary/Confidential" vs. "open" ... how is this supposed > to work ? :-) :-) :-) My mistake: I made the case open and intended to delete such things but obviously I missed one. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From mws@zion.sfbay.sun.com Fri May 9 16:09:03 2008 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 m49N93EY001202 for ; Fri, 9 May 2008 16:09:03 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m49N92hI000108; Fri, 9 May 2008 16:09:03 -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 <0K0M00K0FIZ20700@brm-avmta-1.central.sun.com>; Fri, 09 May 2008 17:09:02 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0M0011JIYS2PC0@brm-avmta-1.central.sun.com>; Fri, 09 May 2008 17:08:52 -0600 (MDT) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m49N8qRK026396; Fri, 09 May 2008 23:08:52 +0000 (GMT) Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m49N8qaE026395; Fri, 09 May 2008 16:08:52 -0700 (PDT) Date: Fri, 09 May 2008 16:08:52 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2008/119 sun4v /dev/bmc In-reply-to: <20080217210831.GA132867@sun.com> To: mws@sun.com (Mike Shapiro) Cc: psarc-ext@sun.com, kyoung.yun@sun.com, mws@sun.com Message-id: <200805092308.m49N8qaE026395@zion.sfbay.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 667 > > I'm sponsoring the follow fast-track for Kyoung Yun. It has binding for a > Micro, with timer set for Friday 2/20. This case was approved some time ago but I made a typo when filing it and said "Micro binding" when I meant "Patch". This functionality is new and adds an interface-compatible thing to SPARC which already existed on x64. Therefore I'd like to propose that this e-mail constitutes a change in the binding to the appropriate "Patch" and the project team can put the functionality into an Update if they so desire. If anyone sees any issues with that, mail back here. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/