From d687068c7018ca46127865c4dba242b5441e0f06 Mon Sep 17 00:00:00 2001 From: Andrew Jones Date: Tue, 1 Sep 2026 17:33:05 +0200 Subject: [PATCH] Update charter for a 2.0 TG Signed-off-by: Andrew Jones --- charter.adoc | 220 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 149 insertions(+), 71 deletions(-) diff --git a/charter.adoc b/charter.adoc index 0c4ca16..d575cb4 100644 --- a/charter.adoc +++ b/charter.adoc @@ -2,97 +2,175 @@ == Introduction -The Server Platform Task Group shall define a specification for a -standardized set of hardware and software capabilities, that portable -system software (such as operating systems and hypervisors) can rely -on being present in a RISC-V server platform. +The Server Platform Task Group shall develop version 2.0 of the RISC-V +Server Platform Specification, building on version 1.0, which was ratified +in May 2026. The main addition will be requirements for virtual server +platforms. The revision will also track changes in dependent specifications, +revisit selected optional requirements, strengthen the treatment of security, +and complete the Server Platform Test Specification. == Definitions -A server is a computing system that is designed to manage and distribute -resources, services and data to other computers or devices on a network. -It is often referred to as a "server" because it serves or provides -information or resources upon request. Such computing systems are -designed to operate continually and have a higher degree of -requirements on RAS, security, performance, quality of service, -etc. Examples of servers include web servers, file servers, database -servers, mail servers, game servers, etc. The focus of this -specification is to define requirements for general purpose server -computing systems that may be used for one or more of these purposes. +A server is a general-purpose computing system intended to provide resources, +services, or data to other systems. Server systems are commonly expected to +operate continuously and to meet higher requirements for reliability, +availability, serviceability (RAS), security, performance, and quality of +service. + +A _physical server platform_ is a platform provided by hardware and platform +firmware rather than by a VMM. + +A _virtual server platform_ is the platform interface presented to a guest +operating system by a virtual machine monitor (VMM). It implements the +applicable server platform requirements with the goal of allowing the same +operating system image to run on conforming physical and virtual platforms. +A virtual platform need not have a corresponding physical implementation and +may expose a different combination of optional features. == Background -It is important to standardize the requirements for ISA, hardware -interfaces and capabilities (e.g. harts, timers, interrupt controllers, -PCIe RCs, RAS, QoS, PMU, etc.), software (OS loader interfaces, hardware -description mechanisms, etc.) and security (e.g. trusted boot) provided by a -server platform, so that operating system and hypervisor vendors may -support such platforms with a single binary OS image distribution. - -Server platform has been chosen as the first platform to standardize, -this being consistent with efforts inside the RISC-V community to -enable general purpose computing platforms. Other platform -standardization efforts may, of course, happen within RVI. -Server platform as the first standardized platform is similar to RVA -ISA Profile being standardized as the first RVI profile. In both of -these cases the efforts are driven by markets that most value and -need standardization. +Version 1.0 defines a common set of hardware, firmware, and security +capabilities for RISC-V servers. Its purpose is to give operating systems and +hypervisors a stable, software-visible platform contract, while relying on +other RISC-V specifications for detailed requirements where appropriate. + +The next revision will address work that was left for later or has emerged +since version 1.0: + +* Version 1.0 does not define conformance for a platform presented to a guest + by a VMM. Virtual platforms need a clear set of requirements and exceptions + if they are to support the same operating system images as physical + platforms. Live migration also requires a stable guest-visible ISA and + consistent behavior for configurable architectural state. + +* Work on the Server SoC, Boot and Runtime Services (BRS), and ISA Profiles + specifications continues to evolve. The Server Platform Specification must + track the applicable ratified versions and avoid duplicating requirements + that are better owned by those specifications. + +* Version 1.0 includes requirements marked SHOULD, including Svadu and Ssctr, + with an expectation that they may become mandatory in a later revision. + Those requirements need to be reviewed against available hardware and + software support. + +* The security rules need further review, particularly around platform + attestation and their relationship to the RISC-V Platform Security Model + and confidential-computing specifications. + +* The Server Platform Test Specification remains in development and contains + incomplete tests. It must be brought up to date with the platform + specification and expanded with OS-level coverage where appropriate. == Objectives -The produced specification will tie together the many hardware and -software requirements for a server platform, many of which are defined -in detail by other RISC-V specs, such as: +=== Maintain the Server Platform Baseline + +The specification shall continue to define software-observable behavior and +interfaces rather than prescribe implementation details. It shall update its +normative references to the appropriate ratified versions of the Server SoC +Specification, BRS, and the RISC-V ISA Profiles. + +When a dependent specification takes ownership of a requirement currently +stated by the Server Platform Specification, the duplicate requirement should +be removed in favor of a reference. Server-specific requirements may remain +where the dependent specification deliberately provides a broader or less +restrictive baseline. + +The TG shall also consider how this specification fits into a broader family +or hierarchy of RISC-V platform specifications. + +The TG shall evaluate emerging server-industry trends, use cases, and +requirements and determine whether they justify additional mandatory or +optional requirements in version 2.0. + +=== Define Virtual Server Platforms + +The TG shall define requirements for virtual server platforms. Early in the +development cycle, it shall decide whether those requirements belong in the +Server Platform Specification or in a separate specification. + +The work shall include: + +* Classifying the version 1.0 requirements as required, optional, or not + applicable for a virtual platform, and defining any necessary additions. +* Defining the platform requirements needed for direct device assignment, in + coordination with the Server SoC Task Group. +* Defining a stable guest-visible ISA baseline, including the treatment of + optional extensions and configurable architectural state, in coordination + with the Profiles Working Group. +* Defining the platform guarantees needed to support VM live migration. + +=== Review Optional Requirements + +The TG shall review version 1.0 requirements that were marked SHOULD with an +expectation of later promotion. A requirement shall be promoted to MUST only +when implementation experience and ecosystem support justify doing so. + +=== Review Security Requirements + +The TG shall review and, where needed, strengthen the version 1.0 security +rules. This work shall include platform attestation and alignment with the +RISC-V Platform Security Model as that specification matures. + +The TG shall also determine which confidential-computing requirements, if +any, belong in a server platform specification and which should instead be +owned by the CoVE, CoVE-IO, Platform Security Model, or other security groups. +The Server Platform Specification should reference those specifications rather +than duplicate their normative content. + +=== Track BRS Development -* ISA Profiles -* Boot and Runtime Services -* Server SoC -* Platform security Model +The firmware rules shall be reviewed against the follow-on BRS work. New +server-relevant requirements shall be incorporated by reference where +possible, and requirements that move into BRS shall not be duplicated in the +Server Platform Specification. -The intent is that most of the normative content is developed by -other TGs and that the Server Platform Specification is the document -that binds everything together and provides a practical architectural -guide to achieve the stated goals. +=== Complete the Test Specification -The specification is meant to be driven by functionality and interoperability -requirements from operating system vendors and solution providers, and thus -concerns itself with systems and application software-observable behavior. -The focus is thus how the system will behave rather than how it will be built. -This is consistent with other specs such as the Server SoC and BRS specifications. +The TG shall correct and complete the existing Server Platform Test +Specification and extend it to cover requirements developed under this charter. +The work shall include OS-level tests where firmware-level tests alone are not +sufficient, as well as tests for virtual-platform features such as live +migration. Tests from dependent specifications should be reused rather than +duplicated. -Where applicable, the produced specification shall reference relevant -industry standards. +The TG shall also identify one or more reference platforms suitable for test +development. The QEMU server platform model is the initial candidate. The TG +shall also consider a physical implementation or a virtual model that closely +matches one. A substantially complete test specification is a prerequisite for +version 2.0 ratification. -It is expected that the Server Platform Specification will add -additional (refining) requirements in relevant areas. For example, -the firmware requirements may be more stringent than the ones covered -in the BRS and include server-specific elements. The specification will -be styled in a manner consistent with the related specs (e.g. Server SoC). +=== Maintain Version 1.0 -The Server Platform TG shall define a coverage plan and approach to -determine compliance to the requirements defined by the -specification. This coverage plan will include and build on the -coverage plans defined by relevant TGs for the dependent specs -(e.g. BRS, Server SoC, etc). This includes a test specification and -a high-level plan for a certification suite. +The TG shall continue to review clarification issues and record errata against +version 1.0. Applicable clarifications and corrections shall be incorporated +into version 2.0. -The Server Platform Specification is expected to be updated -periodically to stay up to date with the evolution of dependent -RISC-V and industry specifications, and to meet the evolving market -requirements identified by RISC-V International stakeholders. +== Exclusions -== Exclusions (Optional) +The specification will not define: -The specification will not cover mechanical, electrical, -thermal, form-factor and performance aspects of a server platform. +* Mechanical, electrical, thermal, form-factor, or performance requirements. +* Service processors or out-of-band management controllers, except for + behavior visible through interfaces used by software running on the + application processors. +* Platform-specific implementation details, such as memory-controller design, + power-management implementation, or hardware initialization sequences. +* The architecture of confidential-computing or trusted-execution mechanisms + that is owned by another RISC-V group. == Collaborations -To fulfill its objectives, the Server Platform Task Group will engage with: +To fulfill these objectives, the Server Platform Task Group will work with: -* Profiles Working Groups -* Boot and Runtime Services Task Group -* Server SoC Task Group -* Platform Security Model Task Group +* The Profiles Working Group on ISA profile updates and guest-visible ISA + consistency. +* The Hypervisors SIG on virtual-platform and live-migration requirements. +* The Boot and Runtime Services Task Group on firmware requirements. +* The Server SoC Task Group on hardware requirements, including support for + virtual-machine device assignment. +* The Platform Security Model Task Group on platform security and attestation. +* The CoVE and CoVE-IO Task Groups on confidential-computing interfaces. +* The Certification Steering Committee on test and certification strategy. -The TG shall be governed by the TSC directly. +The TG shall be governed directly by the Technical Steering Committee (TSC).