FWARC Questions 1. What specifically is the proposal that we are reviewing? This is the niagara-api component of the sun4v/projectQ case. (FWARC/2004/510) This case describes the niagara-api used by guests on a Niagara prorcessor based system to access Niagara processor specific information, such as performance registers. 2. What is the motivation for it? Allows a guest to obtain processor specific performance registers without compromizing system intergrity. 3. What is its plan? dev-complete, ships with the Ontario Platform 4. Are there related projects in Sun? This is part of the sun4v/ProjectQ umbrella case (2004/510) sun4v umbrella FWARC/2004/510 sun4v core API FWARC/2005/116 20050222_john.johnson.3 sun4v io-api FWARC/2005/112 20050222_david.kahn.2 sun4v bus bindings FWARC/2005/111 20050222_david.kahn sun4v machine description FWARC/2005/115 20050222_john.johnson.2 sun4v Ontario Interfaces FWARC/2005/117 20050222_john.johnson.4 sun4v vBSC FWARC/2005/081 20050208_jack.hayward sun4v vendor-specific FCodes FWARC/2005/114 20050222_john.johnson sun4v "pci" device binding TBD - fast-track 5. What is the technical content of the project? A list of APIs based on the Sun4v Core APIs (using the same trap numbers and argument/result format as the core API) for Niagara processor specific interfaces. 6. How is the project delivered into the system? These interfaces are implemented and exported by the hypervisor, which is delivered as part of the platform firmware, and included in the firmware consolidation. 7. What are the project's hardware platform dependencies? Is it expected to work on all systems (Desktop thru servers)? The processor must implement the sun4v sun-sparc extensions described in the sun4v Architecture Specification. 8. What is its FW operational environment: The sun4v core API document describes the interface. Basically, we use a hyperpriv. trap, and pass arguements and results in registers between the guest and the hypervisor. The interface is the trap number, function number, arguments and results for each call documented in this API. 9. What is its user interface (tty, graphical, leds, sound, etc.)? None. 10. What are your project's other external interfaces (exported and imported)? The interfaces are based on the Sun4v Core API (for CPUs and memory). The interfaces are exported to the guest (sun4v OBP and sun4v OS), and imported by them. For the most part, the Niagara APIs will be imported by the Niagara CPU module. The interfaces could be used by any OS (linux, for example) and are documented sufficiently, though a clear proof won't exist for other OS' until a port is done for that OS. These interfaces are classified as "Sun Private". 11. What are its other significant internal interfaces (inter-subsystem and inter-invocation)? None. 12. Is the interface extensible? How is the interface expected to evolve? * How is versioning handled? A generic versioning interface is provided. * What was the commitment level of the previous version? Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? N/A. This is the first version. The versioning and interfaces are designed to allow evolution. A given platform can decide to support the current version and/or future versions of the API, depending on the requirements of the platform A common versioning API will be included to allow any client to query which version(s) of the NIAGARA API are implemented by the firmware on that platform. New functions will be added by using new function numbers. * What are the clients over which a change should be managed? How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? The clients are OBP and any OS that ports to sun4v. * Does this scale from low-end Desktops to high-end Servers? What, if any, trade-offs are involved? Yes it scales. No known tradeoffs. 13. How do the interfaces adapt to a changing world? * What is its relationship with (or difficulties with) System Service Processors? There is no direct relationship with the service processor for the Niagara API. * What security issues do you address in your project? None. 14. What internationalization issues are involved? N/A None. 15. How will the project contribute (positively or negatively) to "system load" and "perceived performance": See FWARC/2004/510 16. How does the project deal with failure and recovery? * How will it respond to failures? (Does it ever require reset? Use of stop key? Can it lock up?) In general, the hypervisor is able to catch failures prior to the guest OS seeing them, and for common types of errors, it can generate FMA reports directly and send them to an FMA server running elsewhere. Reports, where needed, are also sent to the guest OS via the usual reporting methods. However, there are no specific failures associated with the proposed Niagara API. * Does it attempt to isolate and contain the failure to allow for automatic recovery? N/A * How does it communicate a fault event? Does it depend on a working console device? N/A 17. Issues? Please identify the issues which you would like the ARC to address. None. 18. Appendices: See case materials. 19. Security These are internal private interfaces. HW provided identifiers are used to distinguish and isolate requests from different guests running on the platform. The sun4v/hypervisor's job is to ensure that only a guest with access to any given resource can access that resource, so security is effectively built-in. The API can only be called by priv. code running on the platform, such as OBP and the OS. #pragma ident "@(#)fwarc-18Q.txt 1.3 03/08/21 SMI"