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 <some command>" 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

Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know

1. Introduction
   1.1. Project/Component Working Name:

        /dev/bmc for sun4v

   1.2. Name of Document Author/Supplier:

        Kyoung-Hwan Yun <kyoung.yun at sun.com>

   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 <jesse.lawrendra at sun.com>

        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 at sun.com
        1.5.2. Responsible Engineer:    kyoung.yun at sun.com
        1.5.3. Marketing Manager:       nathalie.nann at sun.com
        1.5.4. Interest List:           turgo-sw at sun.com
                                        turgo-eteam at sun.com
                                        turgo-ipmi at 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.

Reply via email to