Date   

[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:
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:

> +====== PCIe cache coherency
> +PCIe transactions that are not marked as No_snoop and access memory
> that is

Greg had few suggestion to change this statement.

"PCIe transactions that are marked with a No Snoop bit of zero and
access memory.."

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?

Yes, I think this is reasonable.

Greg


[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

Kumar Sankaran
 

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:

> +====== PCIe cache coherency
> +PCIe transactions that are not marked as No_snoop and access memory
> that is

Greg had few suggestion to change this statement.

"PCIe transactions that are marked with a No Snoop bit of zero and
access memory.."

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 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
Greg 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
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 Firm
ware 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
--
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:
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?

Yes.
 
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?

The thought thus far has very much been the latter.

Greg


Re: [PATCH v1] System Peripherals - watchdog timer

Abner Chang
 



Greg Favor <gfavor@...> 於 2021年7月9日 週五 下午12:40寫道:
On Thu, Jul 8, 2021 at 8:24 PM Abner Chang <renba.chang@...> wrote:
If the watchdog timer remains un-refreshed for a second period,
+then a second-stage watchdog timeout occurs.
Does it mean the second-stage watchdog timer would be timeout 1 second after the first-stage watchdog timer has not been updated?

What the sentence is actually referring to is the following:

The first watchdog timeout is based on a first programmable timeout period, and the second watchdog timeout is based on a second (separately) programmable timeout period.
ah, got it. thanks. I thought that "a second period" refers to one second.

On the server platform, firmware usually updates the watchdog timer in the background even under OS in runtime. When the watchdog interrupt is triggered, the firmware takes over, sends the log to BMC, and asks BMC to either shutdown or reset the system according to scenarios. We don't like to see OS or hypervisor in the middle to delay the system recovery, for example, OS or processor is somehow halted and the temperature in the box goes pretty high rapidly.
Is 1 second too long for the crisis recovery? Should the first-stage watchdog timer be able to configure as either M or S mode interrupt? So firmware can handle the crisis immediately.

Note that we're spec'ing similar behaviors to what others, like SBSA, spec.  Also note that, in SBSA for example, there are both non-secure and secure watchdogs.  The above watchdog is equivalent to a non-secure watchdog.  Whereas I think what you're thinking of corresponds to a secure watchdog timer - which is controlled by secure software (analogous to M-mode software).  Whereas the non-secure watchdog is controlled by non-secure software, i.e. the OS or hypervisor.
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

Greg


Re: [PATCH v1] System Peripherals - watchdog timer

Mayuresh Chitale
 





On Fri, Jul 9, 2021 at 8:54 AM Abner Chang <renba.chang@...> wrote:


Mayuresh Chitale <mchitale@...> 於 2021年7月7日 週三 上午1:42寫道:
This patch describes requirements for the watchdog timer
for the server extension.

Signed-off-by: Greg Favor <gfavor@...>
Signed-off-by: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..3b5728a 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -470,6 +470,28 @@ 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.
+
+===== Watchdog Timers
+Implementation of a two-stage watchdog timer, as defined in the WatchDog Timer
+appendix footnote:[Watchdog Timer Appendix (TBD)] ,is required. Software must
+periodically refresh the watchdog timer, otherwise a first-stage watchdog
+timeout occurs. If the watchdog timer remains un-refreshed for a second period,
+then a second-stage watchdog timeout occurs.
Does it mean the second-stage watchdog timer would be timeout 1 second after the first-stage watchdog timer has not been updated?
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.

On the server platform, firmware usually updates the watchdog timer in the background even under OS in runtime. When the watchdog interrupt is triggered, the firmware takes over, sends the log to BMC, and asks BMC to either shutdown or reset the system according to scenarios. We don't like to see OS or hypervisor in the middle to delay the system recovery, for example, OS or processor is somehow halted and the temperature in the box goes pretty high rapidly.
Is 1 second too long for the crisis recovery? Should the first-stage watchdog timer be able to configure as either M or S mode interrupt? So firmware can handle the crisis immediately.

Abner

+
+If a first-stage watchdog timeout occurs, a Supervisor-level interrupt request
+is generated and sent to the system interrupt controller, targeting a specific
+hart.
+
+If a second-stage watchdog timeout occurs, a system-level interrupt request is
+generated and sent to a system component more privileged than Supervisor-mode
+such as:
+
+- The system interrupt controller, with a Machine-level interrupt request
+targeting a specific hart
+- A platform management processor
+- Dedicated reset control logic
+
+The resultant action taken is platform-specific.
 * PCI-E

 ==== Secure Boot
--
2.17.1







Re: [PATCH v1] System Peripherals - watchdog timer

Greg Favor
 

On Thu, Jul 8, 2021 at 8:24 PM Abner Chang <renba.chang@...> wrote:
If the watchdog timer remains un-refreshed for a second period,
+then a second-stage watchdog timeout occurs.
Does it mean the second-stage watchdog timer would be timeout 1 second after the first-stage watchdog timer has not been updated?

What the sentence is actually referring to is the following:

The first watchdog timeout is based on a first programmable timeout period, and the second watchdog timeout is based on a second (separately) programmable timeout period.

On the server platform, firmware usually updates the watchdog timer in the background even under OS in runtime. When the watchdog interrupt is triggered, the firmware takes over, sends the log to BMC, and asks BMC to either shutdown or reset the system according to scenarios. We don't like to see OS or hypervisor in the middle to delay the system recovery, for example, OS or processor is somehow halted and the temperature in the box goes pretty high rapidly.
Is 1 second too long for the crisis recovery? Should the first-stage watchdog timer be able to configure as either M or S mode interrupt? So firmware can handle the crisis immediately.

Note that we're spec'ing similar behaviors to what others, like SBSA, spec.  Also note that, in SBSA for example, there are both non-secure and secure watchdogs.  The above watchdog is equivalent to a non-secure watchdog.  Whereas I think what you're thinking of corresponds to a secure watchdog timer - which is controlled by secure software (analogous to M-mode software).  Whereas the non-secure watchdog is controlled by non-secure software, i.e. the OS or hypervisor.

Greg


Re: [PATCH v1] System Peripherals - watchdog timer

Abner Chang
 



Mayuresh Chitale <mchitale@...> 於 2021年7月7日 週三 上午1:42寫道:
This patch describes requirements for the watchdog timer
for the server extension.

Signed-off-by: Greg Favor <gfavor@...>
Signed-off-by: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..3b5728a 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -470,6 +470,28 @@ 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.
+
+===== Watchdog Timers
+Implementation of a two-stage watchdog timer, as defined in the WatchDog Timer
+appendix footnote:[Watchdog Timer Appendix (TBD)] ,is required. Software must
+periodically refresh the watchdog timer, otherwise a first-stage watchdog
+timeout occurs. If the watchdog timer remains un-refreshed for a second period,
+then a second-stage watchdog timeout occurs.
Does it mean the second-stage watchdog timer would be timeout 1 second after the first-stage watchdog timer has not been updated?

On the server platform, firmware usually updates the watchdog timer in the background even under OS in runtime. When the watchdog interrupt is triggered, the firmware takes over, sends the log to BMC, and asks BMC to either shutdown or reset the system according to scenarios. We don't like to see OS or hypervisor in the middle to delay the system recovery, for example, OS or processor is somehow halted and the temperature in the box goes pretty high rapidly.
Is 1 second too long for the crisis recovery? Should the first-stage watchdog timer be able to configure as either M or S mode interrupt? So firmware can handle the crisis immediately.

Abner

+
+If a first-stage watchdog timeout occurs, a Supervisor-level interrupt request
+is generated and sent to the system interrupt controller, targeting a specific
+hart.
+
+If a second-stage watchdog timeout occurs, a system-level interrupt request is
+generated and sent to a system component more privileged than Supervisor-mode
+such as:
+
+- The system interrupt controller, with a Machine-level interrupt request
+targeting a specific hart
+- A platform management processor
+- Dedicated reset control logic
+
+The resultant action taken is platform-specific.
 * PCI-E

 ==== Secure Boot
--
2.17.1






681 - 700 of 1847