|
Re: [PATCH v4 1/1] server extension: PCIe requirements
Mayuresh Chitale
On Thu, Jul 15, 2021 at 11:55 AM Atish Patra <Atish.Patra@...> wrote: On Mon, 2021-07-12 at 23:19 +0530, Mayuresh Chitale wrote: Thanks Atish. Actually one more revision is required for this patch. During an internal review, a modification was suggested to me for the PCIe cache coherency requirement text. I will do that and send a v5 shortly. Please check that as well. --
|
|
|
|
Re: [PATCH v4 1/1] server extension: PCIe requirements
atishp@...
On Mon, 2021-07-12 at 23:19 +0530, Mayuresh Chitale wrote:
This patch adds requirements for PCIe support for the server extensionReviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish
|
|
|
|
[PATCH v2 3/3] Add PMU section
atishp@...
Signed-off-by: Atish Patra <atish.patra@...>
--- riscv-platform-spec.adoc | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5f52edf47a44..574734fc6243 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -72,6 +72,9 @@ The M platform has the following extensions: |APLIC | Advanced PLIC |AIA | Advanced Interrupt Architecture |IMSIC | Incomning MSI Controller +|L1D | L1 Data cache +|LL | Last level cache +|DTLB | DATA TLB cache |=== === Specifications @@ -103,6 +106,18 @@ to all hart-related caches. ==== PMU +The RVA22 profile defines 32 PMU counters out-of-which first three counters are +defined by the privilege specification while other 29 counters are programmable. +The SBI PMU extension defines a set of hardware events that can be monitored using +these programmable counters. This section defines the minimum number of programmable +counters and hardware events required for an OS-A compatible platform. + +* Counters +** The platform do not require to implement any of the programmable counters. +* Events +** The platform do not require to implement any of the hardware events defined +in SBI PMU extensions. + ==== Debug The OS-A base platform requirements are - @@ -409,6 +424,24 @@ The platforms which conform to server extension are required to implement + ==== PMU +* Counters +** The platform must implement at least 8 programmable counters. +* Events +** Hardware general events +*** The platform must implement all of the general hardware events defined by +the SBI PMU extension. +** Hardware cache events +*** The platform must implement all of the hardware cache events for READ operations +while WRITE operation must be implemented for L1D, LL and DTLB caches. + +[sidebar] +-- +[underline]*_Implementation Note_* + +Any platform that do not implement the micro-architectural features related to +a hardware event may hardwire the event value to zero. +-- + ==== Debug The OS-A server platform requirements are all of the base above plus: -- 2.31.1
|
|
|
|
[PATCH v2 2/3] Remove the old descriptions from user-level.adoc
atishp@...
The first three details belong to a profile specification rather than
platform spec. Remove those so that it can be included in the profile. The last remaining one belongs to platform spec but must be merged to the main specification document which will be done later. Signed-off-by: Atish Patra <atish.patra@...> --- user-level.adoc | 6 ------ 1 file changed, 6 deletions(-) diff --git a/user-level.adoc b/user-level.adoc index c02f852036c8..2742d98acaac 100644 --- a/user-level.adoc +++ b/user-level.adoc @@ -7,12 +7,6 @@ ## User-Level Platform -* User-mode environments must implement at least version 2.2 of the RISC-V User - ISA specification, which can be found at - https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf. -* User-mode programs may not execute the `fence.i` instruction. -* User-mode environments may provide additional ISA extensions, but if those - extensions add user-visible state they must be initially disabled. * Within main-memory regions, aligned instruction fetch must be atomic, up to the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word is stored with the `sw` instruction, then any processor attempts to execute -- 2.31.1
|
|
|
|
[PATCH v2 1/3] Remove old & redundant sections.
atishp@...
The platform and profile specification mean different things now.
All the points specified in supervisor.adoc are already described in the new revamped platform spec. Remove these old specifications. Signed-off-by: Atish Patra <atish.patra@...> --- Makefile | 2 +- profiles.adoc | 10 ---------- supervisor-level.adoc | 26 -------------------------- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 profiles.adoc delete mode 100644 supervisor-level.adoc diff --git a/Makefile b/Makefile index de5e0b0309e9..eab98e413b99 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,7 @@ ASCIIDOCTOR = asciidoctor PLATFORM_SPEC = riscv-platform-spec PANDOC = pandoc PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \ - profiles.adoc supervisor-level.adoc user-level.adoc + user-level.adoc # Build the platform spec in several formats all: $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html diff --git a/profiles.adoc b/profiles.adoc deleted file mode 100644 index fdd7fc0f63cc..000000000000 --- a/profiles.adoc +++ /dev/null @@ -1,10 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// profiles.adoc: original Profiles content -// -// This is material from the very first draft of the spec. -// - -## Profiles - -* Portable UNIX Platform Profile diff --git a/supervisor-level.adoc b/supervisor-level.adoc deleted file mode 100644 index 325614a05d32..000000000000 --- a/supervisor-level.adoc +++ /dev/null @@ -1,26 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// supervisor-level.adoc: original Supervisor Level Platform content -// -// This is material from the very first draft of the spec. -// - -## Supervisor-Level Platform - -* Supervisor-mode environments must implement at least version 0.2.0 of the - RISC-V SBI specification, which can be found at - https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc -* Supervisor-mode environments must implement the Sv39 page-based - virtual-memory scheme. Systems that support Sv48 must support Sv39, systems - that support Sv57 must support Sv48, and so forth. -* Unless otherwise specified by a given I/O device, I/O regions are at least - point-to-point strongly ordered. All devices attached to a given PCIe root - complex are on the same ordered channel (numbered 2 or above), though - different root complexes might not be on the same ordering channel. -* On RV64I-based Unix-class systems the negative virtual addresses are reserved - for the kernel. -* External devices (DMA engines, the debug unit, non RISC-V cores, etc) that - are visible to RISC-V harts must appear as coherent agents, just like any - RISC-V hart would. If additional ordering constraints are necessary for a - device to function, those will be provided by a device-specific mechanism. - -- 2.31.1
|
|
|
|
[PATCH v4 1/1] server extension: PCIe requirements
Mayuresh Chitale
This patch adds requirements for PCIe support for the server extension
Signed-off-by: Mayuresh Chitale <mchitale@...> --- Makefile | 18 +++-- pcie-topology.ditaa | 28 ++++++++ riscv-platform-spec.adoc | 147 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 185 insertions(+), 8 deletions(-) create mode 100644 pcie-topology.ditaa diff --git a/Makefile b/Makefile index de5e0b0..06796f3 100644 --- a/Makefile +++ b/Makefile @@ -3,13 +3,19 @@ # ASCIIDOCTOR = asciidoctor +DITAA = ditaa +IMAGES = pcie-topology.png PLATFORM_SPEC = riscv-platform-spec PANDOC = pandoc PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \ profiles.adoc supervisor-level.adoc user-level.adoc # Build the platform spec in several formats -all: $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html +all: $(IMAGES) $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html + +%.png: %.ditaa + rm -f $@ + $(DITAA) $< $(PLATFORM_SPEC).md: $(PLATFORM_SPEC).xml $(PANDOC) -f docbook -t markdown_strict $< -o $@ @@ -17,10 +23,10 @@ $(PLATFORM_SPEC).md: $(PLATFORM_SPEC).xml $(PLATFORM_SPEC).xml: $(PLATFORM_SPEC).adoc $(ASCIIDOCTOR) -d book -b docbook $< -$(PLATFORM_SPEC).pdf: $(PLATFORM_SPEC).adoc +$(PLATFORM_SPEC).pdf: $(PLATFORM_SPEC).adoc $(IMAGES) $(ASCIIDOCTOR) -d book -r asciidoctor-pdf -b pdf $< -$(PLATFORM_SPEC).html: $(PLATFORM_SPEC).adoc +$(PLATFORM_SPEC).html: $(PLATFORM_SPEC).adoc $(IMAGES) $(ASCIIDOCTOR) -d book -b html $< $(PLATFORM_SPEC).adoc: $(PARTS) @@ -31,11 +37,11 @@ clean: rm -f $(PLATFORM_SPEC).md rm -f $(PLATFORM_SPEC).pdf rm -f $(PLATFORM_SPEC).html + rm -f $(IMAGES) # handy shortcuts for installing necessary packages: YMMV install-debs: - sudo apt-get install pandoc asciidoctor ruby-asciidoctor-pdf + sudo apt-get install pandoc asciidoctor ditaa ruby-asciidoctor-pdf install-rpms: - sudo dnf install pandoc rubygem-asciidoctor rubygem-asciidoctor-pdf - + sudo dnf install ditaa pandoc rubygem-asciidoctor rubygem-asciidoctor-pdf diff --git a/pcie-topology.ditaa b/pcie-topology.ditaa new file mode 100644 index 0000000..7180035 --- /dev/null +++ b/pcie-topology.ditaa @@ -0,0 +1,28 @@ + +----------+ +----------+ + | CPU | | CPU | + +-----+----+ +-----+----+ + | | + | | + | | + +-------------+------------+ +-------------+------------+ + | | | | + | Root Complex | | Root Complex | + | | | | + | +--------------+ | | +--------------+ | + | | Host Bridge | | | | Host Bridge | | + | +------+-------+ | | +------+-------+ | + | | | | | | + | | | | | Bus 0 | + | +-------+------+ | | +-----+-------+ | + | | Bus 0 | | | | Root Port | | + | | | | | +-----+-------+ | + | +---+---+ +---+---+ | | | | + | | RCiEP | | RCEC | | | | PCIe Link | + | +-------+ +-------+ | | | | + | | | Bus 1 | | + | | | | | + +--------------------------+ +--------------------------+ + + + RCiEP : Root complex integrated endpoint + RCEC : Root complex event collector diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 4418788..b2949dc 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -47,7 +47,20 @@ include::profiles.adoc[] |RVA22 | RISC-V Application 2022 |EE | Execution Environment |RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC. -|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +|PCIe | PCI Express +|ECAM | Enhanced Configuration Access Mechanism +|BAR | Base Address Register +|AER | Advanced Error Reporting +|CRS | Configuration Request Retry Status +|TLP | Transaction Layer Packet +|RCiEP | Root Complex Integrated Endpoint +|RCEC | Root Complex Event Collector +|PME | Power Management Event +|MSI | Message Signaled Interrupts +|MSI-X | Enhanced Message Signaled Interrupts +|INTx | PCIe Legacy Interrupts +|PMA | Physical Memory Attributes |=== === Specifications @@ -363,7 +376,137 @@ https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension. ** Platforms are required to delegate the supervisor timer interrupt to 'S' mode. If the 'H' extension is implemented then the platforms are required to delegate the virtual supervisor timer interrupt to 'VS' mode. -* PCI-E + +===== PCIe +Platforms are required to support at least PCIe Base Specification Revision 1.1 +footnote:[https://pcisig.com/specifications]. + +====== PCIe Config Space +* Platforms shall support access to the PCIe config space via ECAM as described +in the PCIe Base specification. +* The entire config space for a single PCIe domain should be accessible via a +single ECAM I/O region. +* Platform firmware should implement the MCFG table as listed in the ACPI System +Description Tables above to allow the operating systems to discover the supported +PCIe domains and map the ECAM I/O region for each domain. +* Platform software shall configure ECAM I/O regions such that the effective +memory attributes are that of a PMA I/O region (i.e. strongly-ordered, +non-cacheable, non-idempotent). + +====== PCIe Memory Space +Platforms are required to map PCIe address space directly in the system address +space and not have any address translation for outbound accesses from harts or +for inbound accesses to any component in the system address space + +* PCIe Outbound Memory + +PCIe devices and bridges/switches frequently implement BARs which only support +32-bit addressing or support 64 bit addressing but do not support prefetchable +memory. To support mapping of such BARs, platforms are required to reserve +some space below 4G for each root port present in the system. + +[sidebar] +-- +[underline]*_Implementation Note_* + +Platform software would likely configure these per root port regions such that +their effective memory attributes are that of a PMA I/O region (i.e. +strongly-ordered, non-cacheable, non-idempotent). Platforms would likely also +reserve some space above 4G to map BARs that support 64 bit addressing and +prefetchable memory which could be configured by the platform software as either +I/O or memory. +-- + +* PCIe Inbound Memory + +For security reasons, platforms must provide a mechanism controlled by M-mode +software to restrict inbound PCIe accesses from accessing regions of address +space intended to be accessible only to M-mode software. + +[sidebar] +-- +[underline]*_Implementation Note_* + +Such an access control mechanism could be analogous to the per-hart PMP +as described in the RISC-V Privileged Architectures specification. +-- + +====== PCIe Interrupts +* Platforms shall support both INTx and MSI/MSI-x interrupts. +* Integration with AIA + +TBD + +====== PCIe cache coherency +PCIe transactions that are marked with a No_Snoop bit of zero and access memory +that is cacheable by harts, as well as accesses to memory that is noncacheable +by harts, are I/O Coherent and no software coherency management is needed. In +contrast, PCIe transactions that are marked with a No_Snoop bit of one and +access memory that is cacheable by harts, must have coherency managed by +software. + +====== PCIe Topology +Platforms are required to implement at least one of the following topologies +and the components required in that topology. + +[#fig_intro1] +.PCIe Topologies +image::pcie-topology.png[width=524,height=218] + +* Host Bridge + +Following are the requirements for host bridges: + +** Any read or write access by a hart to an ECAM I/O region shall be converted +by the host bridge into the corresponding PCIe config read or config write +request. +** Any read or write access by a hart to a PCIe outbound region shall be +forwarded by the host bridge to a BAR or prefetch/non-prefetch memory window, +if the address falls within the region claimed by the BAR or prefetch/ +non-prefetch memory window. Otherwise the host bridge shall return an error. + +** Host bridge shall return all 1s in the following cases: +*** Config read to non existent functions and devices on root bus. +*** Config reads that receive Unsupported Request response from functions and +devices on the root bus. +* Root ports + +Following are the requirements for root ports. +** Root ports shall appear as PCI-PCI bridge to software. +** Root ports shall implement all registers of Type 1 header. +** Root ports shall implement all capabilities specified in the PCIe Base +specification for a root port. +** Root ports shall forward type 1 configuration access when the bus number in +the TLP is greater than the root port's secondary bus number and less than or +equal to the root port's subordinate bus number. +** Root ports shall convert type 1 configuration access to a type 0 +configuration access when bus number in the TLP is equal to the root port's +secondary bus number. +** Root ports shall respond to any type 0 configuration accesses it receives. +** Root ports shall forward memory accesses targeting its prefetch/non-prefetch +memory windows to downstream components. If address of the transaction does not +fall within the regions claimed by prefetch/non-prefetch memory windows then +the root port shall generate a Unsupported Request. +** Root port requester id or completer id shall be formed using the bdf of the +root port. +** The root ports shall support the CRS software visibility. +** The root port shall implement the AER capability. +** Root ports shall return all 1s in the following cases: +*** Config read to non existent functions and devices on secondary bus. +*** Config reads that receive Unsupported Request from downstream components. +*** Config read when root port's link is down. + +* RCiEP + +All the requirements for RCiEP in the PCIe Base specification shall be +implemented. +In addition the following requirements shall be met: +** If RCiEP is implemented then RCEC shall be implemented as well. All +requirements for RCEC specified in the PCIe Base specification shall be +implemented. RCEC is required to terminate the AER and PME messages from RCiEP. +** If both the topologies mentioned above are supported then RCiEP and RCEC +shall be implemented in a separate PCIe domain and shall be addressable via a +separate ECAM I/O region. + +===== PCIe Device Firmware Requirement +PCI expansion ROM code type 3 (UEFI) image must be provided by PCIe device for +OS/A server extension platform according to +https://pcisig.com/specifications/conventional/pci_firmware[PCI Firmware Specification Revision 3.3] +if that PCIe device is utilized during UEFI firmware boot process. The image +stored in PCI expansion ROM is an UEFI driver that must be compliant with +https://uefi.org/specifications[UEFI specification 2.9] 14.4.2 PCI Option ROMs. ==== Secure Boot * TEE -- 2.17.1
|
|
|
|
[PATCH v4 0/1] System peripherals - PCIe
Mayuresh Chitale
V4:
- Fix Pcie cache coherency requirement to use 'No_Snoop bit' instead of 'No_snoop' - Removed empty section for peer-to-peer transactions V3: - Replaced references to PMA+PBMT by PMA - Moved the PCIe topology diagram to a separate adoc to enable it's inclusion into PDF V2: - Fixed abbreviation for root complex integrated endpoint - Added section for PCIe device firmware requirement. V1: - Initial patch. Mayuresh Chitale (1): server extension: PCIe requirements Makefile | 18 +++-- pcie-topology.ditaa | 28 ++++++++ riscv-platform-spec.adoc | 150 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 188 insertions(+), 8 deletions(-) create mode 100644 pcie-topology.ditaa -- 2.17.1
|
|
|
|
Re: [PATCH v3 1/1] server extension: PCIe requirements
Mayuresh Chitale
On Sat, Jul 10, 2021 at 4:06 AM Greg Favor <gfavor@...> wrote:
Yes, I think this is reasonable.
|
|
|
|
[PATCH] riscv-platform-spec: ACPI for OS-A Base Spec
Rahul Pathak
ACPI Requirement for OS-A Base Discovery mechanism.
This requirement adds ACPI as an choice for discovery mechanism which firmware can implement. In case the firmware supports both Devicetree and ACPI, firmware must ensure that only one of the mechanism is loaded in memory and provided to OS at any given time. For RISC-V there are required tables of SMBIOS which are required along with ACPI and they are also added as requirement. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc | 82 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 4c356b8..708b48c 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -257,8 +257,88 @@ mentioned in the requirements. - MBR support is not required ===== Discovery Mechanisms -- Device Tree (DT) is the required mechanism for system description. - Compliance with the System Description Specification is required – TBD +- Platforms must implement atleast one of the choices below - + * Devicetree + * ACPI and SMBIOS, only if platform implements AIA APLIC with AIA IMSIC for + interrupts. Refer Interrupt Controller chapter for details. + +- Firmware may support both Devicetree and ACPI but only one of them must be +provided to the OS. + + + + +====== ACPI +If the firmware implements ACPI as discovery mechanism then ACPI tables can be +passed via UEFI to the operating system. This section defines the required ACPI +tables and objects. All other ACPI tables for RISC-V can be implemented as +needed adhering to the ACPI spec version 6.4+(RISC-V support when added). + +In ACPI namespace, processors are required to be defined under the System Bus +*(\_SB)* name space. + +The required ACPI System Description Tables, Device Objects and Methods are +listed below. + +.Required ACPI System Description Tables +[cols="3,1,2", width=95%, align="center", options="header"] +|=== +|ACPI Table |ACPI 6.4+ $|Note +|Root System Description Pointer (RSDP) |5.2.5 | +|Extended System Description Table (XSDT) |5.2.8 | +|Fixed ACPI Description Table (FADT) |5.2.9 | +|Differentiated System Description Table (DSDT)|5.2.11.1 | +|Multiple APIC Description Table (MADT) |5.2.12 |*TBD*: Need ECR + to add + APLIC & IMSIC + (AIA) to MADT +|RISC-V Timer Description Table |New |*TBD*: _DSD to + communicate + timebase-frequency? +|Processor Properties Topology Table (PPTT) |5.2.29 |CPU/Cache topology + information +|Debug Port Table 2 (DBG2) |Microsoft |*TBD*: 16550D? +|Serial Port Console Redirection (SPCR) |Microsoft |*TBD*: 16550D? +|PMU event mapping table |New |*TBD*: New table + required +|=== + +.Required Device Objects and Methods +[cols="1,2,3", width=95%, align="center", options="header"] +|=== +|Object/Method | ACPI 6.4+ $ | Note +|_AEI | 5.6.5.2 | Required for GPIO-signalled events. +|_EVT | 5.6.5.3 | Required for interrupt-signalled events. +|_HID | 6.1.5 | +|_UID | 6.1.12 | +|_CRS | 6.2.2 | +|_CCA | 6.2.17 | Required for DMA capable devices +|_STA | 6.3.7/7.2.4 | Device status +|=== + +====== SMBIOS + +The System Management BIOS (SMBIOS) records provide basic hardware and +firmware configuration information used widely by the platform management +applications. + +The SMBIOS table is identified using *SMBIOS3_TABLE_GUID* in UEFI configuration +table. The memory type used for the SMBIOS table is required to be of type +*EfiRuntimeServicesData*. + +In addition to the conformance guidelines as mentioned in *ANNEX A / 6.2* of +the SMBIOS specification 3.4.0, below additional structures are required. + +.Required SMBIOS structures +[cols="4,1,2", width=95%, align="center", options="header"] +|=== +|Structure Type | SMBIOS 3.4.0 $ | Note +|Processor Additional Information (Type 44) | 7.45 | This +structure provides the additional information of RISC-V processor +characteristics and HART hardware features discovered during the firmware boot +process. +|=== ==== Runtime Services -- 2.25.1
|
|
|
|
Next Platform HSC Meeting on Mon Jul 12th 2021 8AM PST
Hi All,
The next platform HSC meeting is scheduled on Mon July 12th at 8AM PST. Here are the details: Agenda and minutes kept on the github wiki: https://github.com/riscv/riscv-platform-specs/wiki Here are the slides: https://docs.google.com/presentation/d/1TQlw6AHjiRcl3J0AsUw9ygVJQFCcwbTfZNpT6ORw0zY/edit#slide=id.gbad4e10c73_0_320 Meeting info Zoom meeting: https://zoom.us/j/2786028446 Passcode: 901897 Or iPhone one-tap : US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 278 602 8446 International numbers available: https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_ Regards Kumar
|
|
|
|
[PATCH 3/3] Add PMU section
atishp@...
Signed-off-by: Atish Patra <atish.patra@...>
--- riscv-platform-spec.adoc | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5f52edf47a44..c59f4b8d4363 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -72,6 +72,9 @@ The M platform has the following extensions: |APLIC | Advanced PLIC |AIA | Advanced Interrupt Architecture |IMSIC | Incomning MSI Controller +|L1D | L1 Data cache +|LL | Last level cache +|DTLB | DATA TLB cache |=== === Specifications @@ -103,6 +106,18 @@ to all hart-related caches. ==== PMU +The RVA22 profile defines 32 PMU counters out-of-which first three counters are +defined by the privilege specification while other 29 counters are programmable. +The SBI PMU extension defines a set of hardware events that can be monitored using +these programmable counters. This section defines the minimum number of programmable +counters and hardware events required for an OS-A compatible platform. + +* Counters +** The platform do not require to implement any of the programmable counters. +* Events +** The platform do not require to implement any of the hardware events defined +in SBI PMU extensions. + ==== Debug The OS-A base platform requirements are - @@ -409,6 +424,16 @@ The platforms which conform to server extension are required to implement + ==== PMU +* Counters +** The platform must implement at least 8 programmable counters. +* Events +** Hardware general events +*** The platform must implement all of the general hardware events defined by +the SBI PMU extension. +** Hardware cache events +*** The platform must implement all of the hardware cache events for READ operations +while WRITE operation must be implemented for L1D, LL and DTLB caches. + ==== Debug The OS-A server platform requirements are all of the base above plus: -- 2.31.1
|
|
|
|
[PATCH 2/3] Remove the old descriptions from user-level.adoc
atishp@...
The first three details belong to a profile specification rather than
platform spec. Remove those so that it can be included in the profile. The last remaining one belongs to platform spec but must be merged to the main specification document which will be done later. Signed-off-by: Atish Patra <atish.patra@...> --- user-level.adoc | 6 ------ 1 file changed, 6 deletions(-) diff --git a/user-level.adoc b/user-level.adoc index c02f852036c8..2742d98acaac 100644 --- a/user-level.adoc +++ b/user-level.adoc @@ -7,12 +7,6 @@ ## User-Level Platform -* User-mode environments must implement at least version 2.2 of the RISC-V User - ISA specification, which can be found at - https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf. -* User-mode programs may not execute the `fence.i` instruction. -* User-mode environments may provide additional ISA extensions, but if those - extensions add user-visible state they must be initially disabled. * Within main-memory regions, aligned instruction fetch must be atomic, up to the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word is stored with the `sw` instruction, then any processor attempts to execute -- 2.31.1
|
|
|
|
[PATCH 1/3] Remove old & redundant sections.
atishp@...
The platform and profile specification mean different things now.
All the points specified in supervisor.adoc are already described in the new revamped platform spec. Remove these old specifications. Signed-off-by: Atish Patra <atish.patra@...> --- Makefile | 2 +- profiles.adoc | 10 ---------- supervisor-level.adoc | 26 -------------------------- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 profiles.adoc delete mode 100644 supervisor-level.adoc diff --git a/Makefile b/Makefile index de5e0b0309e9..eab98e413b99 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,7 @@ ASCIIDOCTOR = asciidoctor PLATFORM_SPEC = riscv-platform-spec PANDOC = pandoc PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \ - profiles.adoc supervisor-level.adoc user-level.adoc + user-level.adoc # Build the platform spec in several formats all: $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html diff --git a/profiles.adoc b/profiles.adoc deleted file mode 100644 index fdd7fc0f63cc..000000000000 --- a/profiles.adoc +++ /dev/null @@ -1,10 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// profiles.adoc: original Profiles content -// -// This is material from the very first draft of the spec. -// - -## Profiles - -* Portable UNIX Platform Profile diff --git a/supervisor-level.adoc b/supervisor-level.adoc deleted file mode 100644 index 325614a05d32..000000000000 --- a/supervisor-level.adoc +++ /dev/null @@ -1,26 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// supervisor-level.adoc: original Supervisor Level Platform content -// -// This is material from the very first draft of the spec. -// - -## Supervisor-Level Platform - -* Supervisor-mode environments must implement at least version 0.2.0 of the - RISC-V SBI specification, which can be found at - https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc -* Supervisor-mode environments must implement the Sv39 page-based - virtual-memory scheme. Systems that support Sv48 must support Sv39, systems - that support Sv57 must support Sv48, and so forth. -* Unless otherwise specified by a given I/O device, I/O regions are at least - point-to-point strongly ordered. All devices attached to a given PCIe root - complex are on the same ordered channel (numbered 2 or above), though - different root complexes might not be on the same ordering channel. -* On RV64I-based Unix-class systems the negative virtual addresses are reserved - for the kernel. -* External devices (DMA engines, the debug unit, non RISC-V cores, etc) that - are visible to RISC-V harts must appear as coherent agents, just like any - RISC-V hart would. If additional ordering constraints are necessary for a - device to function, those will be provided by a device-specific mechanism. - -- 2.31.1
|
|
|
|
Re: [PATCH v3 1/1] server extension: PCIe requirements
Greg Favor
On Fri, Jul 9, 2021 at 12:58 PM Atish Patra <atish.patra@...> wrote: On Fri, 2021-07-09 at 23:04 +0530, Mayuresh Chitale wrote: Yes, this updated/improved text should be used in place of the version in the patch. (Among other things, this avoids the above double-negative and addresses a concern against using "No_snoop" - which isn't universally used.) Whether we use "No_snoop" (like ARM does) or "No Snoop" (like other people use), or use "No_Snoop", I don't have a strong leaning. Maybe "No_Snoop" is a reasonable middle ground? Greg
|
|
|
|
Re: [PATCH v3 1/1] server extension: PCIe requirements
atishp@...
On Fri, 2021-07-09 at 23:04 +0530, Mayuresh Chitale wrote:
This patch adds requirements for PCIe support for the serverGreg had few suggestion to change this statement. "PCIe transactions that are marked with a No Snoop bit of zero and access memory.." +cacheable by harts, as well as accesses to memory that is-- Regards, Atish
|
|
|
|
[PATCH v3 1/1] server extension: PCIe requirements
Mayuresh Chitale
This patch adds requirements for PCIe support for the server extension
Signed-off-by: Mayuresh Chitale <mchitale@...> --- Makefile | 18 +++-- pcie-topology.ditaa | 28 ++++++++ riscv-platform-spec.adoc | 149 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 187 insertions(+), 8 deletions(-) create mode 100644 pcie-topology.ditaa diff --git a/Makefile b/Makefile index de5e0b0..06796f3 100644 --- a/Makefile +++ b/Makefile @@ -3,13 +3,19 @@ # ASCIIDOCTOR = asciidoctor +DITAA = ditaa +IMAGES = pcie-topology.png PLATFORM_SPEC = riscv-platform-spec PANDOC = pandoc PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \ profiles.adoc supervisor-level.adoc user-level.adoc # Build the platform spec in several formats -all: $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html +all: $(IMAGES) $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html + +%.png: %.ditaa + rm -f $@ + $(DITAA) $< $(PLATFORM_SPEC).md: $(PLATFORM_SPEC).xml $(PANDOC) -f docbook -t markdown_strict $< -o $@ @@ -17,10 +23,10 @@ $(PLATFORM_SPEC).md: $(PLATFORM_SPEC).xml $(PLATFORM_SPEC).xml: $(PLATFORM_SPEC).adoc $(ASCIIDOCTOR) -d book -b docbook $< -$(PLATFORM_SPEC).pdf: $(PLATFORM_SPEC).adoc +$(PLATFORM_SPEC).pdf: $(PLATFORM_SPEC).adoc $(IMAGES) $(ASCIIDOCTOR) -d book -r asciidoctor-pdf -b pdf $< -$(PLATFORM_SPEC).html: $(PLATFORM_SPEC).adoc +$(PLATFORM_SPEC).html: $(PLATFORM_SPEC).adoc $(IMAGES) $(ASCIIDOCTOR) -d book -b html $< $(PLATFORM_SPEC).adoc: $(PARTS) @@ -31,11 +37,11 @@ clean: rm -f $(PLATFORM_SPEC).md rm -f $(PLATFORM_SPEC).pdf rm -f $(PLATFORM_SPEC).html + rm -f $(IMAGES) # handy shortcuts for installing necessary packages: YMMV install-debs: - sudo apt-get install pandoc asciidoctor ruby-asciidoctor-pdf + sudo apt-get install pandoc asciidoctor ditaa ruby-asciidoctor-pdf install-rpms: - sudo dnf install pandoc rubygem-asciidoctor rubygem-asciidoctor-pdf - + sudo dnf install ditaa pandoc rubygem-asciidoctor rubygem-asciidoctor-pdf diff --git a/pcie-topology.ditaa b/pcie-topology.ditaa new file mode 100644 index 0000000..7180035 --- /dev/null +++ b/pcie-topology.ditaa @@ -0,0 +1,28 @@ + +----------+ +----------+ + | CPU | | CPU | + +-----+----+ +-----+----+ + | | + | | + | | + +-------------+------------+ +-------------+------------+ + | | | | + | Root Complex | | Root Complex | + | | | | + | +--------------+ | | +--------------+ | + | | Host Bridge | | | | Host Bridge | | + | +------+-------+ | | +------+-------+ | + | | | | | | + | | | | | Bus 0 | + | +-------+------+ | | +-----+-------+ | + | | Bus 0 | | | | Root Port | | + | | | | | +-----+-------+ | + | +---+---+ +---+---+ | | | | + | | RCiEP | | RCEC | | | | PCIe Link | + | +-------+ +-------+ | | | | + | | | Bus 1 | | + | | | | | + +--------------------------+ +--------------------------+ + + + RCiEP : Root complex integrated endpoint + RCEC : Root complex event collector diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 4418788..24be2d2 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -47,7 +47,20 @@ include::profiles.adoc[] |RVA22 | RISC-V Application 2022 |EE | Execution Environment |RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC. -|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +|PCIe | PCI Express +|ECAM | Enhanced Configuration Access Mechanism +|BAR | Base Address Register +|AER | Advanced Error Reporting +|CRS | Configuration Request Retry Status +|TLP | Transaction Layer Packet +|RCiEP | Root Complex Integrated Endpoint +|RCEC | Root Complex Event Collector +|PME | Power Management Event +|MSI | Message Signaled Interrupts +|MSI-X | Enhanced Message Signaled Interrupts +|INTx | PCIe Legacy Interrupts +|PMA | Physical Memory Attributes |=== === Specifications @@ -363,7 +376,139 @@ https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension. ** Platforms are required to delegate the supervisor timer interrupt to 'S' mode. If the 'H' extension is implemented then the platforms are required to delegate the virtual supervisor timer interrupt to 'VS' mode. -* PCI-E + +===== PCIe +Platforms are required to support at least PCIe Base Specification Revision 1.1 +footnote:[https://pcisig.com/specifications]. + +====== PCIe Config Space +* Platforms shall support access to the PCIe config space via ECAM as described +in the PCIe Base specification. +* The entire config space for a single PCIe domain should be accessible via a +single ECAM I/O region. +* Platform firmware should implement the MCFG table as listed in the ACPI System +Description Tables above to allow the operating systems to discover the supported +PCIe domains and map the ECAM I/O region for each domain. +* Platform software shall configure ECAM I/O regions such that the effective +memory attributes are that of a PMA I/O region (i.e. strongly-ordered, +non-cacheable, non-idempotent). + +====== PCIe Memory Space +Platforms are required to map PCIe address space directly in the system address +space and not have any address translation for outbound accesses from harts or +for inbound accesses to any component in the system address space + +* PCIe Outbound Memory + +PCIe devices and bridges/switches frequently implement BARs which only support +32-bit addressing or support 64 bit addressing but do not support prefetchable +memory. To support mapping of such BARs, platforms are required to reserve +some space below 4G for each root port present in the system. + +[sidebar] +-- +[underline]*_Implementation Note_* + +Platform software would likely configure these per root port regions such that +their effective memory attributes are that of a PMA I/O region (i.e. +strongly-ordered, non-cacheable, non-idempotent). Platforms would likely also +reserve some space above 4G to map BARs that support 64 bit addressing and +prefetchable memory which could be configured by the platform software as either +I/O or memory. +-- + +* PCIe Inbound Memory + +For security reasons, platforms must provide a mechanism controlled by M-mode +software to restrict inbound PCIe accesses from accessing regions of address +space intended to be accessible only to M-mode software. + +[sidebar] +-- +[underline]*_Implementation Note_* + +Such an access control mechanism could be analogous to the per-hart PMP +as described in the RISC-V Privileged Architectures specification. +-- + +====== PCIe Interrupts +* Platforms shall support both INTx and MSI/MSI-x interrupts. +* Integration with AIA + +TBD + +====== PCIe cache coherency +PCIe transactions that are not marked as No_snoop and access memory that is +cacheable by harts, as well as accesses to memory that is noncacheable by +harts, are I/O Coherent and no software coherency management is needed. +In contrast, PCIe transactions that are marked as No_snoop and access memory +that is cacheable by harts, must have coherency managed by software. + +====== PCIe Topology +Platforms are required to implement at least one of the following topologies +and the components required in that topology. + +[#fig_intro1] +.PCIe Topologies +image::pcie-topology.png[width=524,height=218] + +* Host Bridge + +Following are the requirements for host bridges: + +** Any read or write access by a hart to an ECAM I/O region shall be converted +by the host bridge into the corresponding PCIe config read or config write +request. +** Any read or write access by a hart to a PCIe outbound region shall be +forwarded by the host bridge to a BAR or prefetch/non-prefetch memory window, +if the address falls within the region claimed by the BAR or prefetch/ +non-prefetch memory window. Otherwise the host bridge shall return an error. + +** Host bridge shall return all 1s in the following cases: +*** Config read to non existent functions and devices on root bus. +*** Config reads that receive Unsupported Request response from functions and +devices on the root bus. +* Root ports + +Following are the requirements for root ports. +** Root ports shall appear as PCI-PCI bridge to software. +** Root ports shall implement all registers of Type 1 header. +** Root ports shall implement all capabilities specified in the PCIe Base +specification for a root port. +** Root ports shall forward type 1 configuration access when the bus number in +the TLP is greater than the root port's secondary bus number and less than or +equal to the root port's subordinate bus number. +** Root ports shall convert type 1 configuration access to a type 0 +configuration access when bus number in the TLP is equal to the root port's +secondary bus number. +** Root ports shall respond to any type 0 configuration accesses it receives. +** Root ports shall forward memory accesses targeting its prefetch/non-prefetch +memory windows to downstream components. If address of the transaction does not +fall within the regions claimed by prefetch/non-prefetch memory windows then +the root port shall generate a Unsupported Request. +** Root port requester id or completer id shall be formed using the bdf of the +root port. +** The root ports shall support the CRS software visibility. +** The root port shall implement the AER capability. +** Root ports shall return all 1s in the following cases: +*** Config read to non existent functions and devices on secondary bus. +*** Config reads that receive Unsupported Request from downstream components. +*** Config read when root port's link is down. + +* RCiEP + +All the requirements for RCiEP in the PCIe Base specification shall be +implemented. +In addition the following requirements shall be met: +** If RCiEP is implemented then RCEC shall be implemented as well. All +requirements for RCEC specified in the PCIe Base specification shall be +implemented. RCEC is required to terminate the AER and PME messages from RCiEP. +** If both the topologies mentioned above are supported then RCiEP and RCEC +shall be implemented in a separate PCIe domain and shall be addressable via a +separate ECAM I/O region. + +===== PCIe Device Firmware Requirement +PCI expansion ROM code type 3 (UEFI) image must be provided by PCIe device for +OS/A server extension platform according to +https://pcisig.com/specifications/conventional/pci_firmware[PCI Firmware Specification Revision 3.3] +if that PCIe device is utilized during UEFI firmware boot process. The image +stored in PCI expansion ROM is an UEFI driver that must be compliant with +https://uefi.org/specifications[UEFI specification 2.9] 14.4.2 PCI Option ROMs. + +====== PCIe peer to peer transactions + +TBD ==== Secure Boot * TEE -- 2.17.1
|
|
|
|
[PATCH v3 0/1] System peripherals - PCIe
Mayuresh Chitale
V3:
- Replaced references to PMA+PBMT by PMA - Moved the PCIe topology diagram to a separate adoc to enable it's inclusion into PDF V2: - Fixed abbreviation for root complex integrated endpoint - Added section for PCIe device firmware requirement. V1: - Initial patch. Mayuresh Chitale (1): server extension: PCIe requirements Makefile | 18 +++-- pcie-topology.ditaa | 28 ++++++++ riscv-platform-spec.adoc | 149 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 187 insertions(+), 8 deletions(-) create mode 100644 pcie-topology.ditaa -- 2.17.1
|
|
|
|
Re: [PATCH v1] System Peripherals - watchdog timer
Greg Favor
On Thu, Jul 8, 2021 at 10:04 PM Abner Chang <renba.chang@...> wrote:
Yes.
The thought thus far has very much been the latter. Greg
|
|
|
|
Re: [PATCH v1] System Peripherals - watchdog timer
Greg Favor <gfavor@...> 於 2021年7月9日 週五 下午12:40寫道：
ah, got it. thanks. I thought that "a second period" refers to one second.
Then what I was referring to would be another dedicated watchdog timer (secure one) managed by the secure software (management mode software) running in RISC-V TEE, right? Shall we define that secure watchdog timer for the server extension now? Or just wait until we have a clear picture of TEE and OpenSBI support for TEE? Abner
|
|
|
|
Re: [PATCH v1] System Peripherals - watchdog timer
Mayuresh Chitale
On Fri, Jul 9, 2021 at 8:54 AM Abner Chang <renba.chang@...> wrote:
No, actually it just means that if the watchdog timer is never refreshed after the first stage timeout then a second stage timeout would occur. The mechanism to configure the timeout value is not specified in this patch but will be specified in the watchdog timer appendix which is TBD.
|
|
|