Update charter for a 2.0 TG

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).