2 Server Platform Hardware Rules

2.1 RISC-V Harts

A RISC-V server platform includes one or more RISC-V application processors and may include one or more service processors. These service processors may provide services such as security and power management to software executing on the application processors, and they may themselves implement the RISC-V ISA. The rules in this section apply solely to harts in the application processors of the SoC.

ID#	Rule
RVA_010	The RISC-V application processor harts in the SoC MUST support the RVA23S64 ISA profile [6].
RVA_020	The RISC-V application processor harts in the SoC MUST support the following extensions: - Sv48 - Sdtrig [7] - Sdext [7] - Zkr - Ssccfg - Ssstrict [6] - Ssaia [8]
These mandates may be moved into a new ISA profile specification. The motivation for requiring Zkr is that servers typically need access to an entropy source at boot time.
RVA_030	The RISC-V application processor harts in the SoC SHOULD support the Svadu extension.
Svadu is expected to become mandatory in a future version of this specification.
RVA_040	The RISC-V application processor harts in the SoC SHOULD support the Ssctr extension ([9]). If the Ssctr extension is implemented, a CTR depth of 32 MUST be supported. Additional CTR depths MAY also be supported.
The motivation for suggesting Ssctr is that similar capabilities from other architectures are used by profile-guided optimization (PGO) tools to improve builds for workloads typical of servers. Implementing a CTR depth of 32 provides a common CTR depth across implementations for purposes of VM migration. Ssctr is expected to become mandatory in a future version of this specification.
RVA_050	The RISC-V application processor harts within a supervisor execution environment (SEE) must all support the same ISA and non-ISA extensions and the same implementation-dependent choices with those extensions, except when such differences do not interfere with architectural state migration and subsequent execution of threads between harts.
Architectural state comprises all ISA-visible state relevant to the SEE, including but not limited to: XLEN, VLEN, cache block sizes, endianness, privilege levels, supported extensions and their versions, and architecturally defined CSRs and their fields. Permitted divergences (non-exhaustive): - Behaviors the ISA marks as RESERVED or UNSPECIFIED (e.g., outcomes explicitly left undefined, reserved encodings, or implementation-defined choices) when such differences do not affect state save/restore or execution correctness upon migration. If an execution thread is migrated, then the state saved from a first hart when restored on a second hart will result in the same execution results when execution is constrained to behavior that is neither RESERVED nor UNSPECIFIED. - Microarchitectural properties not architecturally visible (e.g., cache sizes/associativity/latency, pipeline depth, frequency, power states). Prohibited divergences (non-exhaustive): - Differences in XLEN, VLEN, cache block sizes, endianness, mandatory privilege features, or any extension that is reported as present within the SEE on any application processor hart. - Differences in the advertised memory consistency model or coherency behavior required by the ISA and platform specification.
RVA_060	The RISC-V application processor MUST support at least 6 hardware performance counters defined by the Zihpm extension in addition to the three counters defined by the Zicntr extension.
The motivation for including at least six performance counters, in addition to the three counters defined by the Zicntr extension, originates from prior experience with x86 servers.

2.2 RISC-V Hart SEE

ID#	Rule
SEE_010	The RISC-V application processor hart MUST support: - Single stepping using the step bit in dcsr
SEE_020	The RISC-V application processor hart MUST support: - At least 4 instruction address match triggers. - At least 4 load/store address match triggers. - At least one icount trigger to support single stepping. - At least one interrupt trigger. - At least one exception trigger. - All triggers MUST support - Privilege mode filtering (VS, VU, S, U). - Meeting the requirements for configuring action=0. - Matching all legal addresses using instruction and load/store address triggers with action=0. - Filtering using mhselect values of 0, 2, and 6. - Filtering using sselect values of 0 and 2. - Triggers MAY support - Filtering using mhselect values of 1 and 5. - Filtering using sselect values of 1. - Supported mhselect and sselect values MUST be identical for all triggers. - When trigger filtering using hcontext is supported, hcontext MUST be at least 14 bits wide, and the filter must support matching all values that can be held in hcontext. - When trigger filtering using scontext is supported, scontext MUST be at least 32 bits wide, and the filter must support matching all values that can be held in scontext.
The motivation for including at least four instruction address and four load/store address match triggers originates from prior experience with x86 servers.

2.3 RISC-V SoC

ID#	Rule
HSOC_010	RISC-V SoCs MUST comply with the Server SoC v1.0 specification [10].
HSOC_020	All SoC peripherals that are intended by the platform design to be assignable to a virtual machine or exposed to a user-space device driver MUST be PCIe devices or comply with the rules for SoC-integrated PCIe devices ([10], Section 2.4).
This rule does not apply to components not intended by the platform for virtual machine or user-space assignment such as: - Interrupt controllers (e.g., APLIC). - IOMMUs. - Debug modules, trace control blocks, RAS banks, and performance monitoring units. - Controllers, including the root of trust (RoT) controllers, power management controllers, and other SoC management controllers.

2.4 Peripherals

ID#	Rule
HPER_010	For remote-access and system engineering purposes in early boot software, either a fully 16550-compatible [11] or a fully pl011-compatible [12] UART MUST be implemented.
This is a stronger requirement than the Server SoC MNG_030 rule [10]. The intention here is to simplify early boot software support requirements. This UART is not intended to be directly assignable to virtual machines, and thus there is no requirement for this UART to appear as a PCI device. This specification does not provide guidance around how the UART is physically exposed, i.e. via RS232 signalling, USB, a BMC or other mechanism.
HPER_020	The implemented UART MUST support: - Interrupt-driven operation using a wired interrupt. - Flow control. - 115200 baud operation.
HPER_030	If a USB controller is implemented, it MUST comply with XHCI 1.2 or later [13].
HPER_040	Implemented XHCI controllers MUST support: - 64-bit addressing (AC64 = '1'). - A 4K PAGESIZE.
HPER_050	If a SATA controller is implemented, it MUST comply with AHCI 1.3.1 or later [14].
HPER_060	Implemented AHCI controllers MUST support: - 64-bit addressing (S64A = '1').
HPER_070	A battery-backed Real Time Clock (the "Server Platform RTC") MUST be implemented for use by platform firmware for UEFI certificate validity checking. This RTC MAY optionally be used by other system functions.
HPER_080	If the operating system does not have access to its own OS-managed Real Time Clock, the Server Platform RTC SHOULD be exposed to the operating system for clock read access via EFI_GET_TIME, and, if the system security profile allows the operating system to change the Server Platform RTC clock, for clock setting access via EFI_SET_TIME.
Allowing operating systems to change the time and date used for UEFI certificate validity checks may have unexpected consequences, including, for example, disrupting certificate verification in platform firmware, or affecting system functions other than the OS that rely on the Server Platform RTC.
HPER_090	A Trusted Platform Module (TPM) MUST be implemented and adhere to the TPM 2.0 Library specification [15].
It is common for secure systems to support multiple trust chains with their own root of trust. For example, a TPM can be secondary root of trust for UEFI boot flows while a hardware RoT is the root of trust for platform firmware, platform attestation, security lifecycle management of the secondary roots of trust, among others.