1. Introduction 1.1. Project/Component Working Name: Virtual IO Dynamic Device Service 1.2. Name of Document Author/Supplier: Raghuram.Kothakota@sun.com 1.3. Date of This Document: Tue Apr 8 13:50:37 EDT 2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: OS PAC 1.4.2. The ARC(s) you expect to review your project: FWARC 1.4.3. The Director/VP who is "Sponsoring" this project: Jerri-Ann Meyer 1.4.4. The name of your business unit: Core Solaris Group 1.5. Email Aliases: 1.5.1. Responsible Manager: Jay.Jayachandran@Sun.Com 1.5.2. Responsible Engineer: Raghuram.Kothakota@Sun.Com 1.5.3. Marketing Manager: Honglin.Su@sun.com 2. Project Summary 2.1. Project Description: The Logical Domains releases to date, provide virtualized I/O for all I/O in and out of the system. While compelling for a variety of application workloads, virtualized I/O will not provide high performance I/O capabilities that networked I/O oriented workloads require. The Hybrid I/O model provides the opportunity to share device resources across multiple client domains with better granularity while overcoming the performance bottlenecks of virtualized I/O. This case extends the Virtual IO protocol to add support for sharing physical device resources with a virtual IO device in guest domain. This is essential to supporting Hybrid IO in a LDoms environment. 2.2. Risks and Assumptions: See FWARC/2006/524 3. Business Summary 3.1. Problem Area: With the current virtual IO model, a logical domain is not provided direct access to network adapters. A service domain with virtual IO services proxies the capabilities of the network device to the logical domain. Though this support is functionally adequate, it lacks the required level of performance and scalability for most applications. Hence, it is critical that the virtual IO model be extended to provide direct access to either the entire network device or some shareable portion of the network device. 3.2. Market/Requester: Niagara platform customers 3.3. Business Justification: Providing improved performance and scalibility for networking is critical to the success of the Niagara based platforms with either N2-NIU or Neptune. 3.4. Competitive Analysis: N/A 3.5. Opportunity Window/Exposure: 3.6. How will you know when you are done?: 4. Technical Description: 4.1 Overview The first release of Logical Domains, Logical Domains version 1.0, provides virtualized I/O for all I/O in and out of the system. While compelling for a variety of application workloads, virtualized I/O will not provide high performance I/O capabilities that networked I/O oriented workloads require. The Hybrid I/O model provides the ability to share device resources across multiple logical domains with better granularity while overcoming the performance bottlenecks of virtualized I/O. The Hybrid I/O model provides direct access of a portion of the I/O device owned and managed by the domain that owns the I/O device. In this model, the I/O bus infrastructure is virtualized and manage by the service domain that owns the I/O bus. When operating in a hybrid mode, VIO devices in a domain with switch dynamically between a proxy based virtual IO and direct hardware access modes without impacting and transparent to the guest OS stack instantiated above the device. This project proposes extensions to Virtual IO protocol to provide the ability to Virtual IO services for sharing physical device resources. The current support allows for proxying the capabilities of a device but with the addition of the Dynamic Device Service (DDS) capability to the VIO protocol, a VIO service can provide its clients direct access to a subset of the underlying device's capabilities. 4.2 Imported Interfaces : Interface Classification Comments ======================================================================= Virtual IO data transfer Sun Private Virtual IO protocol protocol defined by FWARC/2006/195 VIO device message tag Sun Private Virtual IO message tags structure defined by FWARC/2006/195 4.3 Exported Interfaces: Interface Classification Comments ======================================================================== VIO device Messages Sub-Type envelope values: VIO_DDS_INFO Sun Private Section 1.1.5 DDS Message Structure Sun Private Section 1.1.5 DDS Message Header Sun Private Section 1.1.5 DDS Payload Sun Private Section 1.1.5 Virtual Network DDS classes: DDS_VNET_NIU Sun Private Section 1.1.7.5 Virtual Network DDS subclasses: DDS_VNET_ADD_SHARE Sun Private Section 1.1.7.5 DDS_VNET_DEL_SHARE Sun Private Section 1.1.7.5 DDS_VNET_REL_SHARE Sun Private Section 1.1.7.5 DDS_VNET_MOD_SHARE Sun Private Section 1.1.7.5 Virtual Network DDS Sun Private Section 1.1.7.5 message structure 5. Reference Documents: The updated virtual IO protocol specification detailing the new messages is provided. 6. Resources and Schedule: 6.1. Projected Availability: Q2 FY09 6.2. Cost of Effort: 6.3. Cost of Capital Resources: Capital resources are subsumed as part of overall product development. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation Name: Delivery of firmware will be platform teams Delivery of sun4v OS will be platform teams (ON) 6.4.2. Contributing OpCo/BU/Division Name: Solaris Core OS Group 6.4.3. Type of PAC Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: No. 6.4.6. Notes/Dependencies: SUN SPARC CPU specification 6.4.7. Target RTI Date/Release: N/A - Not a separate deliverable. 6.4.8. Target Code Design Review Date: Q4FY08 6.4.9. Update approval addition: N/A 6.5. ARC review type: Fast Track 7. Prototype Availability: 7.1. Prototype Availability: Q3FY08 7.2. Prototype Cost: Done using existing resources.