Date   

Re: [PATCH v2 1/1] server extension: PCIe requirements

Abner Chang
 

Looks good.
Reviewed-by: Abner Chang <abner.chang@...>

Mayuresh Chitale <mchitale@...> 於 2021年7月2日 週五 上午12:50寫道:

This patch adds requirements for PCIe support for the server extension

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 174 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 172 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..e738585 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ 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
+|PBMT      | Page Based Memory Types
 |===

 === Specifications
@@ -363,7 +377,163 @@ 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 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 type (PMA + PBMT) is UC.
+
+====== 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 type (PMA + PBMT) is UC. 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.
+
+[ditaa]
+....
+
+            +----------+                             +----------+
+            |   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
+....
+
+* 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







Re: [PATCH 1/1] Initial commit of PLIC

atishp@...
 

On Sun, 2021-06-20 at 21:32 +0800, Abner Chang wrote:
From: Abner Chang <abner.chang@...>

This is the commit for creating the patches for
widely review in Platform Spec HSC task group

Signed-off-by: Abner Chang <abner.chang@...>
---
 riscv-plic.adoc | 306 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 306 insertions(+)
 create mode 100644 riscv-plic.adoc

diff --git a/riscv-plic.adoc b/riscv-plic.adoc
new file mode 100644
index 0000000..b770e0e
--- /dev/null
+++ b/riscv-plic.adoc
@@ -0,0 +1,306 @@
+= *RISC-V Platform-Level Interrupt Controller Specification*
+
+== Copyright and license information
+
+This RISC-V PLIC specification is
+
+[%hardbreaks]
+(C) 2017 Drew Barbier <drew@...>
+(C) 2018-2019 Palmer Dabbelt <palmer@...>
+(C) 2019 Abner Chang, Hewlett Packard Enterprise <
abner.chang@...>
+
+It is licensed under the Creative Commons Attribution 4.0
International
+License (CC-BY 4.0).  The full license text is available at
+https://creativecommons.org/licenses/by/4.0/.
+
+== Introduction
+
+This document contains the RISC-V platform-level interrupt controller
(PLIC)
+specification, which defines an interrupt controller specifically
designed to
+work in the context of RISC-V systems.  The PLIC multiplexes various
device
+interrupts onto the external interrupt lines of Hart contexts, with
+hardware support for interrupt priorities. +
+This specification defines the general PLIC architecture and operation
parameters.
+The PLIC which claimed as PLIC-Compliant standard PLIC should follow
the
+implementations mentioned in sections below.
+
+.Figure 1 RISC-V PLIC Interrupt Architecture Block Diagram
+image::Images/PLIC.jpg[GitHub,1000,643, link=
https://github.com/riscv/riscv-plic-spec/blob/master/Images/PLIC.jpg]
+
+== RISC-V PLIC Operation Parameters
+
+General PLIC operation parameter register blocks are defined in this
spec, those are: +
+
+- *Interrupt Priorities registers:* +
+   The interrupt priority for each interrupt source. +
+
+- *Interrupt Pending Bits registers:* +
+   The interrupt pending status of each interrupt source. +
+  
+- *Interrupt Enables registers:* +
+   The enablement of interrupt source of each context. +
+
+- *Priority Thresholds registers:* +
+   The interrupt priority threshold of each context. +
+
+- *Interrupt Claim registers:* +
+   The register to acquire interrupt source ID of each context. +
+  
+- *Interrupt Completion registers:* +
+   The register to send interrupt completion message to the associated
gateway. +
+
++
+
+Below is the figure of PLIC Operation Parameter Block Diagram,
+
+.Figure 2 PLIC Operation Parameter Block Diagram
+image::Images/PLICArch.jpg[GitHub, link=
https://github.com/riscv/riscv-plic-spec/blob/master/Images/PLICArch.jpg
]
+
+== Memory Map
+
+The `base address of PLIC Memory Map` is platform implementation-
specific.
+
+*PLIC Memory Map*
+
+       base + 0x000000: Reserved (interrupt source 0 does not exist)
+       base + 0x000004: Interrupt source 1 priority
+       base + 0x000008: Interrupt source 2 priority
+       ...
+       base + 0x000FFC: Interrupt source 1023 priority
+       base + 0x001000: Interrupt Pending bit 0-31
+       base + 0x00107C: Interrupt Pending bit 992-1023
+       ...     
+       base + 0x002000: Enable bits for sources 0-31 on context 0
+       base + 0x002004: Enable bits for sources 32-63 on context 0
+       ...
+       base + 0x00207F: Enable bits for sources 992-1023 on context 0
+       base + 0x002080: Enable bits for sources 0-31 on context 1
+       base + 0x002084: Enable bits for sources 32-63 on context
1     
+       ...
+       base + 0x0020FF: Enable bits for sources 992-1023 on context 1
+       base + 0x002100: Enable bits for sources 0-31 on context 2
+       base + 0x002104: Enable bits for sources 32-63 on context
2     
+       ...
+       base + 0x00217F: Enable bits for sources 992-1023 on context 2
+       ...
+       base + 0x1F1F80: Enable bits for sources 0-31 on context 15871
+       base + 0x1F1F84: Enable bits for sources 32-63 on context
15871         
+       base + 0x1F1FFF: Enable bits for sources 992-1023 on context
15871
+       ...     
+       base + 0x1FFFFC: Reserved
+       base + 0x200000: Priority threshold for context 0
+       base + 0x200004: Claim/complete for context 0
+       base + 0x200008: Reserved
+       ...
+       base + 0x200FFC: Reserved
+       base + 0x201000: Priority threshold for context 1
+       base + 0x201004: Claim/complete for context 1
+       ...
+       base + 0x3FFE000: Priority threshold for context 15871
+       base + 0x3FFE004: Claim/complete for context 15871
+       base + 0x3FFE008: Reserved
+       ...     
+       base + 0x3FFFFFC: Reserved
+       
+Sections below describe the control register blocks of PLIC operation
parameters.
+
+== Register Width
+
+The memory map register width is in 32-bit.
+
+== Interrupt Priorities
+
+If PLIC supports Interrupt Priorities, then each PLIC interrupt source
can be assigned a priority by writing to its 32-bit
+memory-mapped `priority` register.  A priority value of 0 is reserved
to mean ''never interrupt'' and effectively
+disables the interrupt. Priority 1 is the lowest active priority while
the maximum level of priority depends on
+PLIC implementation. Ties between global interrupts of the same
priority are broken by the Interrupt ID; interrupts
+with the lowest ID have the highest
+effective priority. +
+ +
+The base address of Interrupt Source Priority block within PLIC Memory
Map region is fixed at 0x000000.
+
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name*| *Function*|*Register Block Size in
Byte*| *Description*
+|Interrupt Source Priority
+|Interrupt Source Priority #0 to #1023
+|1024 * 4 = 4096(0x1000) bytes
+|This is a continuously memory block which contains PLIC Interrupt
Source Priority. Total 1024 Interrupt Source Priority
+in this memory block. Interrupt Source Priority #0 is reserved which
indicates it does not exist.
+|===
+
+*PLIC Interrupt Source Priority Memory Map* +
+
+       0x000000: Reserved (interrupt source 0 does not exist)
+       0x000004: Interrupt source 1 priority
+       0x000008: Interrupt source 2 priority
+       ...
+       0x000FFC: Interrupt source 1023 priority
+
+== Interrupt Pending Bits
+
+The current status of the interrupt source pending bits in the PLIC
core can be
+read from the pending array, organized as 32-bit register.  The
pending bit
+for interrupt ID N is stored in bit (N mod 32) of word (N/32).  Bit 0
+of word 0, which represents the non-existent interrupt source 0, is
hardwired
+to zero.
+
+A pending bit in the PLIC core can be cleared by setting the
associated enable
+bit then performing a claim. +
+ +
+The base address of Interrupt Pending Bits block within PLIC Memory
Map region is fixed at 0x001000.
+
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name* | *Function*|*Register Block Size in
Byte*| *Description*
+|Interrupt Pending Bits
+|Interrupt Pending Bit of Interrupt Source #0 to #N
+|1024 / 8 = 128(0x80) bytes
+|This is a continuously memory block contains PLIC Interrupt Pending
Bits. Each Interrupt Pending Bit occupies 1-bit from this register
block.
+|===
+
+*PLIC Interrupt Pending Bits Memory Map* +
+
+       0x001000: Interrupt Source #0 to #31 Pending Bits
+       ...
+       0x00107C: Interrupt Source #992 to #1023 Pending Bits
+
+
+== Interrupt Enables
+
+Each global interrupt can be enabled by setting the corresponding bit
in the
+`enables` register. The `enables` registers are accessed as a
contiguous array
+of 32-bit registers, packed the same way as the `pending` bits. Bit 0
of enable
+register 0 represents the non-existent interrupt ID 0 and is hardwired
to 0.
+PLIC has 15872 Interrupt Enable blocks for the contexts. The `context`
is referred
+to the specific privilege mode in the specific Hart of specific RISC-V
processor
+instance. How PLIC organizes interrupts for the contexts (Hart and
privilege mode)
+is out of RISC-V PLIC specification scope, however it must be spec-out
in vendor's
+PLIC specification. +
+ +
+The base address of Interrupt Enable Bits block within PLIC Memory Map
region is fixed at 0x002000. +
+ +
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name* | *Function*|*Register Block Size in
Byte*| *Description*
+|Interrupt Enable Bits
+|Interrupt Enable Bit of Interrupt Source #0 to #1023 for 15872
contexts
+|(1024 / 8) * 15872 = 2031616(0x1f0000) bytes
+|This is a continuously memory block contains PLIC Interrupt Enable
Bits of 15872 contexts.
+Each Interrupt Enable Bit occupies 1-bit from this register block and
total 15872 Interrupt
+Enable Bit blocks
+|===
+
+*PLIC Interrupt Enable Bits Memory Map* +
+
+       0x002000: Interrupt Source #0 to #31 Enable Bits on context 0
+       ...
+       0x00207F: Interrupt Source #992 to #1023 Enable Bits on context
0
+       0x002080: Interrupt Source #0 to #31 Enable Bits on context 1
+       ...
+       0x0020FF: Interrupt Source #992 to #1023 Enable Bits on context
1
+       0x002100: Interrupt Source #0 to #31 Enable Bits on context 2
+       ...
+       0x00217F: Interrupt Source #992 to #1023 Enable Bits on context
2
+       0x002180: Interrupt Source #0 to #31 Enable Bits on context 3
+       ...
+       0x0021FF: Interrupt Source #992 to #1023 Enable Bits on context
3
+       ...
+       ...
+       ...
+       0x1F1F80: Interrupt Source #0 to #31 on context 15871   
+       ...     
+       0x1F1F80: Interrupt Source #992 to #1023 on context 15871
+       
+== Priority Thresholds
+
+PLIC provides context based `threshold register` for the settings of a
interrupt priority
+threshold of each context. The `threshold register` is a WARL field.
The PLIC will mask all
+PLIC interrupts of a priority less than or equal to `threshold`.  For
example,
+a`threshold` value of zero permits all interrupts with non-zero
priority. +
+ +
+The base address of Priority Thresholds register block is located at
4K alignement starts
+from offset 0x200000.
+
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name* | *Function*|*Register Block Size in
Byte*| *Description*
+|Priority Threshold
+|Priority Threshold for 15872 contexts
+|4096 * 15872 = 65011712(0x3e00000) bytes
+|This is the register of Priority Thresholds setting for each conetxt
+|===
+
+*PLIC Interrupt Priority Thresholds Memory Map* +
+
+       0x200000: Priority threshold for context 0
+       0x201000: Priority threshold for context 1
+       0x202000: Priority threshold for context 2
+       0x203000: Priority threshold for context 3
+       ...
+       ...
+       ...
+       0x3FFF000: Priority threshold for context 15871
+       
+== Interrupt Claim Process
+
+The PLIC can perform an interrupt claim by reading the
`claim/complete`
+register, which returns the ID of the highest priority pending
interrupt or
+zero if there is no pending interrupt.  A successful claim will also
atomically
+clear the corresponding pending bit on the interrupt source. +
+The PLIC can perform a claim at any time and the claim operation is
not affected
+by the setting of the priority threshold register. +
+The Interrupt Claim Process register is context based and is located
at
+(4K alignement + 4) starts from offset 0x200000.
+
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name* | *Function*|*Register Block Size in
Byte*| *Description*
+|Interrupt Claim Register
+|Interrupt Claim Process for 15872 contexts
+|4096 * 15872 = 65011712(0x3e00000) bytes
+|This is the register used to acquire interrupt ID for each conetxt
+|===
+
+*PLIC Interrupt Claim Process Memory Map* +
+
+       0x200004: Interrupt Claim Process for context 0
+       0x201004: Interrupt Claim Process for context 1
+       0x202004: Interrupt Claim Process for context 2
+       0x203004: Interrupt Claim Process for context 3
+       ...
+       ...
+       ...
+       0x3FFF004: Interrupt Claim Process for context 15871
+       
+## Interrupt Completion
+
+The PLIC signals it has completed executing an interrupt handler by
writing the
+interrupt ID it received from the claim to the `claim/complete`
register.  The
+PLIC does not check whether the completion ID is the same as the last
claim ID
+for that target.  If the completion ID does not match an interrupt
source that
+is currently enabled for the target, the completion is silently
ignored. +
+The Interrupt Completion registers are context based and located at
the same address
+with Interrupt Claim Process register, which is at (4K alignement + 4)
starts from
+offset 0x200000.
+ +
+[cols="15%,20%,20%,45%"]
+|===
+| *PLIC Register Block Name* | *Registers*|*Register Block Size in
Byte*| *Description*
+|Interrupt Completion Register
+|Interrupt Completion  for 15872 contexts
+|4096 * 15872 = 65011712(0x3e00000) bytes
+|This is register to write to complete Interrupt process
+|===
+
+*PLIC Interrupt Completion Memory Map* +
+
+       0x200004: Interrupt Completion for context 0
+       0x201004: Interrupt Completion for context 1
+       0x202004: Interrupt Completion for context 2
+       0x203004: Interrupt Completion for context 3
+       ...
+       ...
+       ...
+       0x3FFF004: Interrupt Completion for context 15871
+
I think it will be good to provide additional clarification in the
beginning about the number of interrupts/contexts. Something along the
lines:

The PLIC specification supports up-to 1024 interrupts and 15872
contexts. But the actual number of interrupts and context depends on
the PLIC implementation. However, the implement must adhere to the
offset of each register within the PLIC block.

Apart from that, LGTM.
Reviewed-by: Atish Patra <atish.patra@...>

--
Regards,
Atish


Re: [PATCH v2] Cache Coherency and ASID Requirements for OS-A platform

atishp@...
 

On Wed, 2021-06-30 at 16:19 -0700, Kumar Sankaran wrote:
Updated v2 of the cache coherency patch
Changes from v1
    Brought in all cache coherency changes after feedback
    Removed ASID requirements

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..3953b5e 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -89,8 +89,13 @@ The M platform has the following extensions:
 * ISA Profile
 ** The OS-A platform is required to comply with the RVA22 profile.
 * Cache Coherency
-* PMU
-* ASID
+** All harts must adhere to the RVWMO memory model.
+** All hart PMA regions for main memory must be marked as coherent.
+** Memory accesses by I/O masters can be coherent or non-coherent with
respect
+to all hart-related caches.
+
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -288,10 +293,11 @@ base with the additional requirements as below.
 ==== Architecture
 The platforms which conform to server extension are required to
implement +

-- RISC-V Hypervisor-level H Instruction-Set Extensions
-- IOMMU with support for memory resident interrupt files
-- PMU
-- ASID
+- RV64 support
+- RISC-V H ISA extension
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -306,6 +312,8 @@ above.
 respect to all harts connected to the DM
   * Rationale: Debuggers must be able to view memory coherently

+==== Interrupt Controller
+
 ==== Boot and Runtime Requirements
 =====  Firmware
 The boot and system firmware for the RV64I server platforms required
to be

Reviewed-by: Atish Patra <atish.patra@...>

--
Regards,
Atish


[PATCH v2 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@...>
---
riscv-platform-spec.adoc | 174 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 172 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..e738585 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ 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
+|PBMT | Page Based Memory Types
|===

=== Specifications
@@ -363,7 +377,163 @@ 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 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 type (PMA + PBMT) is UC.
+
+====== 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 type (PMA + PBMT) is UC. 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.
+
+[ditaa]
+....
+
+ +----------+ +----------+
+ | 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
+....
+
+* 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 v2 0/1] System peripherals - PCIe

Mayuresh Chitale
 

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

riscv-platform-spec.adoc | 174 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 172 insertions(+), 2 deletions(-)

--
2.17.1


[PATCH v2] Cache Coherency and ASID Requirements for OS-A platform

Kumar Sankaran
 

Updated v2 of the cache coherency patch
Changes from v1
Brought in all cache coherency changes after feedback
Removed ASID requirements

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..3953b5e 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -89,8 +89,13 @@ The M platform has the following extensions:
* ISA Profile
** The OS-A platform is required to comply with the RVA22 profile.
* Cache Coherency
-* PMU
-* ASID
+** All harts must adhere to the RVWMO memory model.
+** All hart PMA regions for main memory must be marked as coherent.
+** Memory accesses by I/O masters can be coherent or non-coherent with respect
+to all hart-related caches.
+
+
+==== PMU

==== Debug
The OS-A base platform requirements are -
@@ -288,10 +293,11 @@ base with the additional requirements as below.
==== Architecture
The platforms which conform to server extension are required to implement +

-- RISC-V Hypervisor-level H Instruction-Set Extensions
-- IOMMU with support for memory resident interrupt files
-- PMU
-- ASID
+- RV64 support
+- RISC-V H ISA extension
+- VMID support
+
+==== PMU

==== Debug
The OS-A server platform requirements are all of the base above plus:
@@ -306,6 +312,8 @@ above.
respect to all harts connected to the DM
* Rationale: Debuggers must be able to view memory coherently

+==== Interrupt Controller
+
==== Boot and Runtime Requirements
===== Firmware
The boot and system firmware for the RV64I server platforms required to be


--
Regards
Kumar


Re: [PATCH 1/1] server extension: PCIe requirements

Mayuresh Chitale
 



On Wed, 30 Jun, 2021, 3:44 PM Abner Chang, <renba.chang@...> wrote:


Mayuresh Chitale <mchitale@...> 於 2021年6月30日 週三 上午12:27寫道:
This patch adds requirements for PCIe support for the server extension

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 164 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..590cf70 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ 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
Suggest using RCiEP (lower case of "I") which is aligned with PCIE spec.
Sure.
 
+|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
+|PBMT      | Page Based Memory Types
 |===

 === Specifications
@@ -363,7 +377,155 @@ 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 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 type (PMA + PBMT) is UC.
+
+====== 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 type (PMA + PBMT) is UC. 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.
+
+[ditaa]
+....
+
+            +----------+                             +----------+
+            |   CPU    |                             |   CPU    |
+            |          |                             |          |
+            +-----|----+                             +-----|----+
+                  |                                        |
+                  |                                        |
+    +-------------|------------+             +-------------|------------+
+    |        ROOT | COMPLEX    |             |        ROOT | COMPLEX    |
+    |                          |             |                          |
+    |      +------|-------+    |             |      +------|-------+    |
+    |      |  Host Bridge |    |             |      |  Host Bridge |    |
+    |      +------|-------+    |             |      +------|-------+    |
+    |             |            |             |             |            |
+    |             | BUS 0      |             |             | BUS 0      |
+    |     |-------|------|     |             |       +-----|-------+    |
+    |     |              |     |             |       | ROOT  PORT  |    |
+    |     |              |     |             |       +-----|-------+    |
+    | +---|---+      +---|---+ |             |             |            |
+    | | RCEIP |      | RCEC  | |             |             | PCIe Link  |
+    | +-------+      +-------+ |             |             |            |
+    |                          |             +-------------|------------+
+    +--------------------------+                           |
+                                                           |  BUS 1
+    RCEIP - Root complex integrated endpoint
+    RCEC - Root complex event collector
+....
+
+* 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.
+
+* RCEIP +
Should this be RCiEP? If yes, then the same issue in the following paragraph.

Yes, I will fix in the next revision.

+All the requirements for RCEIP in the PCIe Base specification shall be
+implemented.
+In addition the following requirements shall be met:
+** If RCEIP 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 RCEIP.
+** If both the topologies mentioned above are supported then RCEIP and RCEC
+shall be implemented in a separate PCIe domain and shall be addressable via a
+separate ECAM I/O region.
+
+====== PCIe peer to peer transactions +
+TBD

 ==== Secure Boot
 * TEE

Did you miss the PCI firmware requirement I mentioned earlier?

Yes, looks like I missed it. I will include it in the next revision.

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


Regards,
Abner
 
--
2.17.1







Re: [PATCH 1/1] server extension: PCIe requirements

Abner Chang
 



Mayuresh Chitale <mchitale@...> 於 2021年6月30日 週三 上午12:27寫道:
This patch adds requirements for PCIe support for the server extension

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 164 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..590cf70 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ 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
Suggest using RCiEP (lower case of "I") which is aligned with PCIE spec.
 
+|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
+|PBMT      | Page Based Memory Types
 |===

 === Specifications
@@ -363,7 +377,155 @@ 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 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 type (PMA + PBMT) is UC.
+
+====== 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 type (PMA + PBMT) is UC. 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.
+
+[ditaa]
+....
+
+            +----------+                             +----------+
+            |   CPU    |                             |   CPU    |
+            |          |                             |          |
+            +-----|----+                             +-----|----+
+                  |                                        |
+                  |                                        |
+    +-------------|------------+             +-------------|------------+
+    |        ROOT | COMPLEX    |             |        ROOT | COMPLEX    |
+    |                          |             |                          |
+    |      +------|-------+    |             |      +------|-------+    |
+    |      |  Host Bridge |    |             |      |  Host Bridge |    |
+    |      +------|-------+    |             |      +------|-------+    |
+    |             |            |             |             |            |
+    |             | BUS 0      |             |             | BUS 0      |
+    |     |-------|------|     |             |       +-----|-------+    |
+    |     |              |     |             |       | ROOT  PORT  |    |
+    |     |              |     |             |       +-----|-------+    |
+    | +---|---+      +---|---+ |             |             |            |
+    | | RCEIP |      | RCEC  | |             |             | PCIe Link  |
+    | +-------+      +-------+ |             |             |            |
+    |                          |             +-------------|------------+
+    +--------------------------+                           |
+                                                           |  BUS 1
+    RCEIP - Root complex integrated endpoint
+    RCEC - Root complex event collector
+....
+
+* 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.
+
+* RCEIP +
Should this be RCiEP? If yes, then the same issue in the following paragraph.
 
+All the requirements for RCEIP in the PCIe Base specification shall be
+implemented.
+In addition the following requirements shall be met:
+** If RCEIP 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 RCEIP.
+** If both the topologies mentioned above are supported then RCEIP and RCEC
+shall be implemented in a separate PCIe domain and shall be addressable via a
+separate ECAM I/O region.
+
+====== PCIe peer to peer transactions +
+TBD

 ==== Secure Boot
 * TEE

Did you miss the PCI firmware requirement I mentioned earlier?

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


Regards,
Abner
 
--
2.17.1







Re: UEFI/ACPI ECR process proposal

Elisa Sawyer <elisa@...>
 

We have the initial draft of an official RISC-V Glossary:


Anyone can can create an issue for the Glossary.

We could append the Glossary to each and every document, however, I think it will be easier to maintain the Glossary as a separate document.

As soon as it's gotten large enough to be useful, it can be posted, and, at that point, other documents can link to it.

- Elisa


On Tue, Jun 29, 2021 at 8:42 AM Mark Himelstein <markhimelstein@...> wrote:
do we have a glossary (with links if apropos)  for the acronyms in use in the docs (like IMSIC)? more than just what the acronym is for but like what the item is for and either a standards definition link or example links.

On Tue, Jun 29, 2021 at 8:36 AM Sunil V L <sunilvl@...> wrote:
Hi Team,

As we discussed in the Platform HSC meeting yesterday, I am attaching the snapshot of the slides presented. Please also go through the https://github.com/riscv/riscv-acpi/wiki/ACPI-ASWG-ECR-Process and get back with any feedback/questions.

Thanks

Sunil







[PATCH 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@...>
---
riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 164 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..590cf70 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ 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
+|PBMT | Page Based Memory Types
|===

=== Specifications
@@ -363,7 +377,155 @@ 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 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 type (PMA + PBMT) is UC.
+
+====== 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 type (PMA + PBMT) is UC. 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.
+
+[ditaa]
+....
+
+ +----------+ +----------+
+ | CPU | | CPU |
+ | | | |
+ +-----|----+ +-----|----+
+ | |
+ | |
+ +-------------|------------+ +-------------|------------+
+ | ROOT | COMPLEX | | ROOT | COMPLEX |
+ | | | |
+ | +------|-------+ | | +------|-------+ |
+ | | Host Bridge | | | | Host Bridge | |
+ | +------|-------+ | | +------|-------+ |
+ | | | | | |
+ | | BUS 0 | | | BUS 0 |
+ | |-------|------| | | +-----|-------+ |
+ | | | | | | ROOT PORT | |
+ | | | | | +-----|-------+ |
+ | +---|---+ +---|---+ | | | |
+ | | RCEIP | | RCEC | | | | PCIe Link |
+ | +-------+ +-------+ | | | |
+ | | +-------------|------------+
+ +--------------------------+ |
+ | BUS 1
+ RCEIP - Root complex integrated endpoint
+ RCEC - Root complex event collector
+....
+
+* 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.
+
+* RCEIP +
+All the requirements for RCEIP in the PCIe Base specification shall be
+implemented.
+In addition the following requirements shall be met:
+** If RCEIP 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 RCEIP.
+** If both the topologies mentioned above are supported then RCEIP and RCEC
+shall be implemented in a separate PCIe domain and shall be addressable via a
+separate ECAM I/O region.
+
+====== PCIe peer to peer transactions +
+TBD

==== Secure Boot
* TEE
--
2.17.1


[PATCH 0/1] System peripherals - PCIe

Mayuresh Chitale
 

This is an initial patch for PCIe requirements for the server extension. The
goal is to specify requirements for those PCIe elements which interact with
the system such as PCIe config space, memory space, topology, interrupts etc.

Mayuresh Chitale (1):
server extension: PCIe requirements

riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 164 insertions(+), 2 deletions(-)

--
2.17.1


Re: UEFI/ACPI ECR process proposal

mark
 

do we have a glossary (with links if apropos)  for the acronyms in use in the docs (like IMSIC)? more than just what the acronym is for but like what the item is for and either a standards definition link or example links.

On Tue, Jun 29, 2021 at 8:36 AM Sunil V L <sunilvl@...> wrote:
Hi Team,

As we discussed in the Platform HSC meeting yesterday, I am attaching the snapshot of the slides presented. Please also go through the https://github.com/riscv/riscv-acpi/wiki/ACPI-ASWG-ECR-Process and get back with any feedback/questions.

Thanks

Sunil







UEFI/ACPI ECR process proposal

Sunil V L
 

Hi Team,

As we discussed in the Platform HSC meeting yesterday, I am attaching the snapshot of the slides presented. Please also go through the https://github.com/riscv/riscv-acpi/wiki/ACPI-ASWG-ECR-Process and get back with any feedback/questions.

Thanks

Sunil


Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension

Abner Chang
 



Jonathan Behrens <behrensj@...> 於 2021年6月29日 週二 上午2:32寫道:
What does "implementation specific" mean in this context? Could the platform spec require implementations to program the RTC with UTC times?
I don't think that is necessary to mention how to program the RTC in platform spec. We just need the RTC to keep counting the time. UEFI Time runtime service already provides the abstract API which the underlying algorithm to program RTC or incorporates with some other mechanisms is not defined.  The example I mentioned to incorporate with BMC is just one of the implementations.

If not, could it recommend/encourage them to?
  Yes, we still can provide some recommendations in the spec that encourages people to use RTC.
Abner
  

Jonathan

On Mon, Jun 28, 2021 at 11:31 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:


Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
On 6/28/21 8:39 AM, Abner Chang wrote:
>
>
> Jonathan Behrens <behrensj@... <mailto:behrensj@...>> 於 2021年6
> 月25日 週五 下午11:11寫道:
>
>     Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require
>     that time is always UTC?
>
> That depends on how do you implement GetTime/SetTime functions for the
> platform.  You can always not returning EFI_UNSPECIFIED_TIMEZONE in the
> implementation and just return the offset to UTC for the local time.
>
> Abner

The way that UEFI reports local time zones is unsatisfactory:

There is an offset to UTC and a daylight savings flag but this does not
allow to derive on which day daylight saving switches (you could be on
the southern or on the northern hemisphere) nor the daylight savings
offset which historically has been one hour or two hours.

Furthermore many RTC chips do not store timezone related information.
EDK II stores it in UEFI variables. There is no handling of daylight
savings switches in EDK II.

With this background allowing anything else but UTC just creates ambiguity.
That's true.

On the server platform, RTC doesn't work alone. It incorporates with BMC to get the time information because only BMC is alive even when the system is powered off. The system only syncs up the time settings from BMC when every time the system boots. GetTime function is used by the firmware or the pre-OS EFI applications. SetTIme is used when the firmware sync up the time with BMC or the server deployment. RTC is the media to keep the time information, how to use RTC is implementation-specific.
Abner

>
>
>     Jonathan
>
>
>     On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org
>     <http://lists.riscv.org> <renba.chang=gmail.com@...
>     <mailto:gmail.com@...>> wrote:
>
>         From: Abner Chang <abner.chang@... <mailto:abner.chang@...>>
>
>         RTC (Real-time Clock)
>             Real-time clock is the server basic system peripheral to
>         provide the real date/time information for server to manage the
>         system date, time and time zones settings for different regions
>         through the local POST time firmware utility, NTP or the remote
>         management such as Redfish.
>
>         Signed-off-by: Abner Chang <renba.chang@...
>         <mailto:renba.chang@...>>
>         Signed-off-by: Abner Chang <abner.chang@...
>         <mailto:abner.chang@...>>
>         ---
>           riscv-platform-spec.adoc | 17 ++++++++++++++---
>           1 file changed, 14 insertions(+), 3 deletions(-)
>
>         diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>         index 87ea6d5..d611d69 100644
>         --- a/riscv-platform-spec.adoc
>         +++ b/riscv-platform-spec.adoc
>         @@ -442,9 +442,9 @@ The UEFI run time services listed below are
>         required to be implemented.
>           |SetVariable               | 8.2        | A dedicated storage
>         for firmware is
>           required so that there is no conflict in access by both
>         firmware and the OS.
>           |QueryVariableInfo         | 8.2        |
>         -|GetTime                   | 8.3        | RTC Access by the OS
>         -|SetTime                   | 8.3        | If it is not possible
>         to set the RTC,
>         -the SetTime() can return an error.
>         +|GetTime                   | 8.3        | RTC Access by the OS
>         and firmware
>         +|SetTime                   | 8.3        | RTC configured by the
>         OS and
>         +firmware
>           |GetWakeupTime             | 8.3        | Interface is
>         required to be
>           implemented but it can return EFI_UNSUPPORTED.
>           |SetWakeupTime             | 8.3        | Interface is
>         required to be
>         @@ -469,6 +469,17 @@
>         https://lists.riscv.org/g/tech-privileged/message/404[Sstc]
>         <https://lists.riscv.org/g/tech-privileged/message/404%5BSstc%5D> 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.
>         +
>         +* Real-time Clock (RTC)
>         +The Real-time clock must be provided to the server extension
>         platform to
>         +facilitate the time management (Date, time and the time zone)
>         and RTC wake up
>         +when the server is in the power down state for the server
>         manageability.
>         +The GetTime()and SetTime() UEFI runtime services must be
>         implemented by
>         +firmware to incorporate with RTC and flexibly support RTC use
>         cases.
>         +GetWakeupTime() and SetWakeupTime() UEFI runtime services are
>         required to be
>         +implemented but it can return EFI_UNSUPPORTED if the wake up
>         from RTC is not
>         +supported.

This paragraph is self-contradictory:

It requires RTC to facilitate "RTC wake up" but allows SetWakeupTime()
to report EFI_UNSUPPORTED.

Best regards

Heinrich

>         +
>           * PCI-E
>
>           ==== Secure Boot
>         --
>         2.19.0.windows.1
>


Re: FW: [riscv/riscv-platform-specs] RVM platform requirements (#25)

Greg Favor
 

On Mon, Jun 28, 2021 at 2:03 PM Kumar Sankaran <ksankaran@...> wrote:

Is it realistic to require RV32G in order to comply with the RVM platform? It seems like a more natural choice would be RV32IMAF, as RV32D is pretty heavy on the floating-point for small microcontrollers (most Cortex-M devices don't even have double precision support in hardware, that's only available in the M55 and M7).


Keep in mind the distinction between RVM ISA profile specs and M platform specs.  I would expect that the M platform spec would require the RVM ISA profile spec.  But all the individual FP and C extensions are "Optional" in RVM20 and RVM22.  The M profile specs generally take the approach of setting a low "Required" bar and specify many extensions as supported but "Optional".

So the M 2022 platform spec can either simply accept that through its requirement for RVM22, or it can add on requirements for the F and C extensions (and possibly some other extensions).  Essentially the M platform spec can choose to require everything that constitutes RV32GC/RV64GC, or to stop a bit short (e.g. not requiring D), or stop way short.

I don't have a horse in this race, but I can imagine there being people on both sides of the argument as to whether the M platform spec should require more than what is required in the M profile spec, and if so how much more.

Greg


FW: [riscv/riscv-platform-specs] RVM platform requirements (#25)

Kumar Sankaran
 

Forwarding to tech mailing list.

 

Regards

Kumar

From: Torbjørn Viem Ness <notifications@...>
Sent: Monday, June 28, 2021 1:34 PM
To: riscv/riscv-platform-specs <riscv-platform-specs@...>
Cc: Subscribed <subscribed@...>
Subject: [riscv/riscv-platform-specs] RVM platform requirements (#25)

 

Great initiative!
I do however have questions about the requirements for the RVM platform, specifically the 32-bit version;

Is it realistic to require RV32G in order to comply with the RVM platform? It seems like a more natural choice would be RV32IMAF, as RV32D is pretty heavy on the floating-point for small microcontrollers (most Cortex-M devices don't even have double precision support in hardware, that's only available in the M55 and M7).

Also the C extension would make sense to include as embedded applications are quite sensitive to code size, but that's probably a different discussion worthy of its own issue...


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension

Jonathan Behrens <behrensj@...>
 

What does "implementation specific" mean in this context? Could the platform spec require implementations to program the RTC with UTC times? If not, could it recommend/encourage them to?

Jonathan

On Mon, Jun 28, 2021 at 11:31 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:


Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
On 6/28/21 8:39 AM, Abner Chang wrote:
>
>
> Jonathan Behrens <behrensj@... <mailto:behrensj@...>> 於 2021年6
> 月25日 週五 下午11:11寫道:
>
>     Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require
>     that time is always UTC?
>
> That depends on how do you implement GetTime/SetTime functions for the
> platform.  You can always not returning EFI_UNSPECIFIED_TIMEZONE in the
> implementation and just return the offset to UTC for the local time.
>
> Abner

The way that UEFI reports local time zones is unsatisfactory:

There is an offset to UTC and a daylight savings flag but this does not
allow to derive on which day daylight saving switches (you could be on
the southern or on the northern hemisphere) nor the daylight savings
offset which historically has been one hour or two hours.

Furthermore many RTC chips do not store timezone related information.
EDK II stores it in UEFI variables. There is no handling of daylight
savings switches in EDK II.

With this background allowing anything else but UTC just creates ambiguity.
That's true.

On the server platform, RTC doesn't work alone. It incorporates with BMC to get the time information because only BMC is alive even when the system is powered off. The system only syncs up the time settings from BMC when every time the system boots. GetTime function is used by the firmware or the pre-OS EFI applications. SetTIme is used when the firmware sync up the time with BMC or the server deployment. RTC is the media to keep the time information, how to use RTC is implementation-specific.
Abner

>
>
>     Jonathan
>
>
>     On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org
>     <http://lists.riscv.org> <renba.chang=gmail.com@...
>     <mailto:gmail.com@...>> wrote:
>
>         From: Abner Chang <abner.chang@... <mailto:abner.chang@...>>
>
>         RTC (Real-time Clock)
>             Real-time clock is the server basic system peripheral to
>         provide the real date/time information for server to manage the
>         system date, time and time zones settings for different regions
>         through the local POST time firmware utility, NTP or the remote
>         management such as Redfish.
>
>         Signed-off-by: Abner Chang <renba.chang@...
>         <mailto:renba.chang@...>>
>         Signed-off-by: Abner Chang <abner.chang@...
>         <mailto:abner.chang@...>>
>         ---
>           riscv-platform-spec.adoc | 17 ++++++++++++++---
>           1 file changed, 14 insertions(+), 3 deletions(-)
>
>         diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>         index 87ea6d5..d611d69 100644
>         --- a/riscv-platform-spec.adoc
>         +++ b/riscv-platform-spec.adoc
>         @@ -442,9 +442,9 @@ The UEFI run time services listed below are
>         required to be implemented.
>           |SetVariable               | 8.2        | A dedicated storage
>         for firmware is
>           required so that there is no conflict in access by both
>         firmware and the OS.
>           |QueryVariableInfo         | 8.2        |
>         -|GetTime                   | 8.3        | RTC Access by the OS
>         -|SetTime                   | 8.3        | If it is not possible
>         to set the RTC,
>         -the SetTime() can return an error.
>         +|GetTime                   | 8.3        | RTC Access by the OS
>         and firmware
>         +|SetTime                   | 8.3        | RTC configured by the
>         OS and
>         +firmware
>           |GetWakeupTime             | 8.3        | Interface is
>         required to be
>           implemented but it can return EFI_UNSUPPORTED.
>           |SetWakeupTime             | 8.3        | Interface is
>         required to be
>         @@ -469,6 +469,17 @@
>         https://lists.riscv.org/g/tech-privileged/message/404[Sstc]
>         <https://lists.riscv.org/g/tech-privileged/message/404%5BSstc%5D> 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.
>         +
>         +* Real-time Clock (RTC)
>         +The Real-time clock must be provided to the server extension
>         platform to
>         +facilitate the time management (Date, time and the time zone)
>         and RTC wake up
>         +when the server is in the power down state for the server
>         manageability.
>         +The GetTime()and SetTime() UEFI runtime services must be
>         implemented by
>         +firmware to incorporate with RTC and flexibly support RTC use
>         cases.
>         +GetWakeupTime() and SetWakeupTime() UEFI runtime services are
>         required to be
>         +implemented but it can return EFI_UNSUPPORTED if the wake up
>         from RTC is not
>         +supported.

This paragraph is self-contradictory:

It requires RTC to facilitate "RTC wake up" but allows SetWakeupTime()
to report EFI_UNSUPPORTED.

Best regards

Heinrich

>         +
>           * PCI-E
>
>           ==== Secure Boot
>         --
>         2.19.0.windows.1
>


Re: Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

Kumar Sankaran
 

https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

Yes, it includes all planned extensions.

 

Regards

Kumar

From: Mark Himelstein <markhimelstein@...>
Sent: Monday, June 28, 2021 11:04 AM
To: Kumar Sankaran <ksankaran@...>
Cc: tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

 

where are the current platform specifications that are under development being stored? does it include extensions?

 

Thanks

Mark

 

On Fri, Jun 25, 2021 at 1:36 PM Kumar Sankaran <ksankaran@...> wrote:

Hi All,
The next platform HSC meeting is scheduled on Mon Jun 28th 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/1BnCDjSxAFqpRlEbyQ4zOrGqoOEp0aQzzoJgTxgDygLk/edit#slide=id.ge09029d4aa_0_0

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





Re: Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

mark
 

where are the current platform specifications that are under development being stored? does it include extensions?

Thanks
Mark

On Fri, Jun 25, 2021 at 1:36 PM Kumar Sankaran <ksankaran@...> wrote:
Hi All,
The next platform HSC meeting is scheduled on Mon Jun 28th 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/1BnCDjSxAFqpRlEbyQ4zOrGqoOEp0aQzzoJgTxgDygLk/edit#slide=id.ge09029d4aa_0_0

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






Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension

Abner Chang
 



Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
On 6/28/21 8:39 AM, Abner Chang wrote:
>
>
> Jonathan Behrens <behrensj@... <mailto:behrensj@...>> 於 2021年6
> 月25日 週五 下午11:11寫道:
>
>     Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require
>     that time is always UTC?
>
> That depends on how do you implement GetTime/SetTime functions for the
> platform.  You can always not returning EFI_UNSPECIFIED_TIMEZONE in the
> implementation and just return the offset to UTC for the local time.
>
> Abner

The way that UEFI reports local time zones is unsatisfactory:

There is an offset to UTC and a daylight savings flag but this does not
allow to derive on which day daylight saving switches (you could be on
the southern or on the northern hemisphere) nor the daylight savings
offset which historically has been one hour or two hours.

Furthermore many RTC chips do not store timezone related information.
EDK II stores it in UEFI variables. There is no handling of daylight
savings switches in EDK II.

With this background allowing anything else but UTC just creates ambiguity.
That's true.

On the server platform, RTC doesn't work alone. It incorporates with BMC to get the time information because only BMC is alive even when the system is powered off. The system only syncs up the time settings from BMC when every time the system boots. GetTime function is used by the firmware or the pre-OS EFI applications. SetTIme is used when the firmware sync up the time with BMC or the server deployment. RTC is the media to keep the time information, how to use RTC is implementation-specific.
Abner

>
>
>     Jonathan
>
>
>     On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org
>     <http://lists.riscv.org> <renba.chang=gmail.com@...
>     <mailto:gmail.com@...>> wrote:
>
>         From: Abner Chang <abner.chang@... <mailto:abner.chang@...>>
>
>         RTC (Real-time Clock)
>             Real-time clock is the server basic system peripheral to
>         provide the real date/time information for server to manage the
>         system date, time and time zones settings for different regions
>         through the local POST time firmware utility, NTP or the remote
>         management such as Redfish.
>
>         Signed-off-by: Abner Chang <renba.chang@...
>         <mailto:renba.chang@...>>
>         Signed-off-by: Abner Chang <abner.chang@...
>         <mailto:abner.chang@...>>
>         ---
>           riscv-platform-spec.adoc | 17 ++++++++++++++---
>           1 file changed, 14 insertions(+), 3 deletions(-)
>
>         diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>         index 87ea6d5..d611d69 100644
>         --- a/riscv-platform-spec.adoc
>         +++ b/riscv-platform-spec.adoc
>         @@ -442,9 +442,9 @@ The UEFI run time services listed below are
>         required to be implemented.
>           |SetVariable               | 8.2        | A dedicated storage
>         for firmware is
>           required so that there is no conflict in access by both
>         firmware and the OS.
>           |QueryVariableInfo         | 8.2        |
>         -|GetTime                   | 8.3        | RTC Access by the OS
>         -|SetTime                   | 8.3        | If it is not possible
>         to set the RTC,
>         -the SetTime() can return an error.
>         +|GetTime                   | 8.3        | RTC Access by the OS
>         and firmware
>         +|SetTime                   | 8.3        | RTC configured by the
>         OS and
>         +firmware
>           |GetWakeupTime             | 8.3        | Interface is
>         required to be
>           implemented but it can return EFI_UNSUPPORTED.
>           |SetWakeupTime             | 8.3        | Interface is
>         required to be
>         @@ -469,6 +469,17 @@
>         https://lists.riscv.org/g/tech-privileged/message/404[Sstc]
>         <https://lists.riscv.org/g/tech-privileged/message/404%5BSstc%5D> 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.
>         +
>         +* Real-time Clock (RTC)
>         +The Real-time clock must be provided to the server extension
>         platform to
>         +facilitate the time management (Date, time and the time zone)
>         and RTC wake up
>         +when the server is in the power down state for the server
>         manageability.
>         +The GetTime()and SetTime() UEFI runtime services must be
>         implemented by
>         +firmware to incorporate with RTC and flexibly support RTC use
>         cases.
>         +GetWakeupTime() and SetWakeupTime() UEFI runtime services are
>         required to be
>         +implemented but it can return EFI_UNSUPPORTED if the wake up
>         from RTC is not
>         +supported.

This paragraph is self-contradictory:

It requires RTC to facilitate "RTC wake up" but allows SetWakeupTime()
to report EFI_UNSUPPORTED.

Best regards

Heinrich

>         +
>           * PCI-E
>
>           ==== Secure Boot
>         --
>         2.19.0.windows.1
>

701 - 720 of 1836