Date   

SBI v0.3.0 released

atishp@...
 

We have released SBI specification v0.3.0[1]. It's been month since the
release candidate (v.0.3-rc1). There were only includes few typo fixes
and license update patches after that. That's why, we think the current
version is good enough to be tagged as a official release.

To summarize v0.3.0 includes few new extensions and cosmetic changes
through out the entire specification.

Here are few notable changes:

- New extensions:
- SBI PMU extension
- SBI System reset extension
- Updated extensions:
- Hart Suspend function added to HSM extension
- Overall specification reorganization and style update


Thank you for your contributions!

[1] https://github.com/riscv/riscv-sbi-doc/releases/tag/v0.3.0

--
Regards,
Atish


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

Mayuresh Chitale
 



On Sat, Jul 3, 2021 at 8:33 PM Atish Patra <Atish.Patra@...> wrote:
On Thu, 2021-07-01 at 22:20 +0530, Mayuresh Chitale wrote:
> 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

MCFG table was not referenced earlier.might

Actually it is present in the 'Required ACPI System Description Tables'. 
I can add a pointer to that table in the text above.


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

UC is not present in abbreviation section. Moreover, PMA + PBMT seems
bit ambiguous to me. It wouldn't hurt to be more verbose here.

I will rephrase all instances of this as Greg mentioned in his latest email. 
> +====== 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
> +I think I can add
> +* 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. 

same comment as above.

> 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

/s/No_snoop/No Snoop ?

PCIe spec does refer to it as No Snoop but ARM BSA refers to it as No_snoop.
I thought the latter was slightly better as it might be easier to understand it as a single attribute or flag :)
  
> +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 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

Apart from the above nit comments, looks good to me.

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

--
Regards,
Atish


[PATCH v1] System Peripherals - watchdog timer

Mayuresh Chitale
 

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.
+
+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 v2 1/1] server extension: PCIe requirements

Greg Favor
 

On Sat, Jul 3, 2021 at 8:03 AM Atish Patra <atish.patra@...> wrote:
> +* Platform software shall configure ECAM I/O regions such that the
> effective
> +memory type (PMA + PBMT) is UC.

UC is not present in abbreviation section. Moreover, PMA + PBMT seems
bit ambiguous to me. It wouldn't hurt to be more verbose here.

The proposed RISC-V name for this memory type is "IO", but it is up in the air for the moment as to whether the the memory types supported by Svpbmt will have acronym names (i.e. IO and NC), or just use thier longer descriptive names, e.g. Non-cacheable, non-idempotent, strongly-ordered I/O memory for "IO".

Overall it is probably better to make the above statement in a somewhat more generic manner terminology-wise.  For example:

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

This implicitly allows for systems that do and don't support Svpbmt.

> +Platform software would likely configure these per root port regions
> such that
> +their effective memory type (PMA + PBMT) is UC. 

same comment as above.

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

/s/No_snoop/No Snoop ?

ARM uses "No_snoop", but others will use No-snoop and No Snoop.  Avoiding the last form avoids any ambiguity when not using it followed by "bit", i.e. "No Snoop bit" is pretty clear, whereas referring to just "No Snoop" as a transaction attribute to some might be ambiguous as to whether "Snoop" or "No Snoop" is the attribute.

Myself, I don't have a significant leaning, but one alternative to the above sentence could be:

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

I maybe lean a little bit towards that last option.  That also avoids use of the linguistic double negative.

Greg


[PATCH V2 2/2] contributors: Add Abner as contributor

Abner Chang
 

From: Abner Chang <abner.chang@...>

Signed-off-by: Abner Chang <abner.chang@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index a1ea5ef..5b150eb 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -29,7 +29,8 @@ Alistair Francis,
Sunil V L,
Rahul Pathak,
Mayuresh Chitale,
-Paul Donahue
+Paul Donahue,
+Abner Chang

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.19.0.windows.1


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

Abner Chang
 

From: Abner Chang <abner.chang@...>

In V2:
Change the section to System Real-time and rephrase the content.

In V1:
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 <abner.chang@...>
---
riscv-platform-spec.adoc | 38 ++++++++++++++++++++++++++++++++------
1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..4774987 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -443,13 +443,16 @@ 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 | System Real-time accessed by the
+OS and firmware.<<SystemRealTime,(Refer to System Real-time section)>>
+|SetTime | 8.3 | System Real-time set by the
+OS and firmware.<<SystemRealTime,(Refer to System Real-time section)>>
|GetWakeupTime | 8.3 | Interface is required to be
-implemented but it can return EFI_UNSUPPORTED.
+implemented but it can return EFI_UNSUPPORTED.<<SystemRealTime,(Refer to
+System Real-time section)>>
|SetWakeupTime | 8.3 | Interface is required to be
-implemented but it can return EFI_UNSUPPORTED.
+implemented but it can return EFI_UNSUPPORTED.<<SystemRealTime,(Refer to
+System Real-time section)>>
|SetVirtualAddressMap | 8.4 |
|ConvertPointer | 8.4 |
|GetNextHighMonotonicCount | 8.5 |
@@ -463,13 +466,36 @@ implemented but it can return EFI_UNSUPPORTED.
|===

==== System Peripherals
-* Clock and Timers
+===== Clock and Timers
** Platforms are required to implement the time CSR.
** Platforms are required to implement the
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.
+
+===== System Real-time[[SystemRealTime]]
+In order to facilitate server manageability, server extension platform is
+required to provide the mechanism to maintain system date and time. The
+mechanism could be the Real-time clock on platform as it mentioned in UEFI
+spec, or other implementations that can provide the date and time information
+to UEFI runtime Time service. +
+The GetTime()and SetTime() UEFI runtime service
+must be implemented by firmware to incorporate with the underlying system
+Real-time mechanism, however the SetTime() is allowed to be unsupported if the
+platform doesn’t require the feature to set date and time or the system
+Real-time mechanism doesn’t have capability to set time. UEFI GetWakeupTime()
+and SetWakeupTime() runtime services are also required to be implemented on
+server extension platform. However, those two runtime services can return
+EFI_UNSUPPORTED to the caller if the wake up from time is not supported by the
+platform. +
+Timezone and Daylight Saving Time (DST) are also defined in UEFI runtime Time
+service, however the system Real-time mechanism may not have the capability
+to maintain this information. Firmware can always return the local time without
+timezone and DST information, or firmware incorporates with other facilities
+such as BMC, UEFI variable or boot time system configuration utility to
+maintain this information with the system Real-time mechanism.
+
* PCI-E

==== Secure Boot
--
2.19.0.windows.1


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

Abner Chang
 


Atish Patra <Atish.Patra@...> 於 2021年7月2日 週五 上午2:40寫道:
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.

Added to spec. 

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

Merged to riscv-plic-spec with Atish and Alistair's Reviewed-by.
Abner

--
Regards,
Atish
 


[PATCH v2 2/2] contributors: Add Abner as contributor

Abner Chang
 

From: Abner Chang <abner.chang@...>

Signed-off-by: Abner Chang <renba.chang@...>
Signed-off-by: Abner Chang <abner.chang@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index a1ea5ef..5b150eb 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -29,7 +29,8 @@ Alistair Francis,
Sunil V L,
Rahul Pathak,
Mayuresh Chitale,
-Paul Donahue
+Paul Donahue,
+Abner Chang

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.19.0.windows.1


[PATCH v2 1/2] riscv-platform-spec: Interrupt Controller

Abner Chang
 

From: Abner Chang <abner.chang@...>

Initial version of Interrupt Controller, Software Interrupt,
and Timer Requirements. This patch combines the text sent out
by Kumar and the patch Abner sent previously.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Kumar Sankaran <ksankaran@...>
Cc: Anup Patel <anup.patel@...>
Signed-off-by: Abner Chang <abner.chang@...>
---
riscv-platform-spec.adoc | 125 +++++++++++++++++++++++++++++++++++++--
1 file changed, 120 insertions(+), 5 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ab7f8..b59dacf 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -64,8 +64,14 @@ The M platform has the following extensions:
|EE | Execution Environment
|OSPM | Operating System Power Management
|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.
|RAS | Reliability, Availability, and Serviceability
+|CLINT | Legacy Core-Local Interrupt Controller
+|ACLINT | Advanced CLINT
+|PLIC | Legacy Platform-Level Interrupt Controller
+|APLIC | Advanced PLIC
+|AIA | Advanced Interrupt Architecture
+|IMSIC | Incomning MSI Controller
|===

=== Specifications
@@ -179,10 +185,114 @@ each must be 1
The default should allow code that's sensitive to these requirements to be
debugged.

-==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+==== Interrupt Controller, Software Interrupt, and Timer Requirements
+In the following requirements,
+https://github.com/riscv/riscv-aia[*AIA*] refers to the Advanced Interrupt Architecture, https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[*ACLINT*]
+refers to the Advanced *CLINT*. AIA comprises two separate components: `IMSICs` and `APLICs`.
+If supported, there is an `IMSIC` device associated with each hart.
+If supported, *APLIC* devices are global to all harts, and there may be one or
+multiple in a system. *ACLINT* comprises three separate components: `MTIMER` for
+Timer support, and `MSWI` and `SSWI` for Machine-level and Supervisor-level
+Software Interrupt (IPI) support. +
+https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[*PLIC*]
+refers to the legacy Platform-Level Interrupt Controller that provides
+facilities to route external interrupts to a hart context with a given privilege
+mode. The number of non-local interrupt sources supported by PLIC and how does
+each of them connect to the hart context is PLIC core implementation-specific. +
+*CLINT* is a legacy Core-Local Interrupt Controller that is a compatible subset of
+ACLINT which provides facilities to trigger Software (IPI) and Timer interrupts to
+hart.
+
+.The following table summarizes what features are supported for four classes of OS/A platforms.
+[width="100%",cols="^,^,^,^,^,^,^,^,^,^,^,^,^"]
+|=======
+.2+|*OS-A Platform* 3+|*MSIs* 3+|*Wired Interrupts* 3+|*IPIs* 3+|*Timer*
+|M-level|S-level|VS-level|M-level|S-level|VS-level|M-level|S-level|VS-level|M-level|S-level|VS-level
+|Existing|NA|NA|NA|PLIC|PLIC|PLIC +
+_(Trap and emulate)_|MSWI +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+SBI IPI +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]|SBI IPI +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]|MTIMER +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|SBI Timer +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]|SBI Timer +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]
+|Only Wired IRQs|NA|NA|NA|APLIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+_(Trap and emulate)_ +
+https://github.com/riscv/riscv-aia[`*AIA*`]|MSWI +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+SSWI +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+SBI IPI +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]|MTIMER +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]
+|MSIs and Wired IRQs|IMSIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+_(Trap and emulate)_ +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+_(Trap and emulate)_ +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|SBI IPI +
+https://github.com/riscv/riscv-sbi-doc[`*SBI*`]|MTIMER +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]
+|MSIs, Virtual MSIs and Wired IRQs|IMSIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC VS-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|APLIC S-level +
+_(Trap and emulate)_ +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC M-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC S-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|IMSIC VS-level +
+https://github.com/riscv/riscv-aia[`*AIA*`]|MTIMER +
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc[`*ACLINT*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]|
+Priv Sstc +
+https://github.com/riscv/riscv-isa-manual/releases[`*Priv Spec*`]
+|=======
+
+* For Timer support, one or more ACLINT MTIMER devices are Required for OS-A platform.
+One MTIMER may be used for all harts, or multiple MTIMERs may be used with
+multiple topological groups of harts. The base address of MTIMER memory map registers
+is platform implementation-specific, however, the format of MTIMER operation parameters
+(`mtime` and `mtimecmp` registers) must be compliant with
+https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#21-register-map[ACLINT MTIMER Register Map]
+
+* For Interrupt Controller and Software Interrupt support, one of the following three
+choices below is Required
+ ** PLIC plus one or more ACLINT MSWI devices - DEPRECATED
+ *** One MSWI may be used for all harts, or multiple MSWIs may be used with
+multiple topological groups of harts
+ *** Only wired interrupts and M-mode IPIs are supported
+ *** Virtualization is not supported
+ *** This compatibly supports legacy PLIC + CLINT designs
+ ** One or more AIA APLIC devices plus one or more pairs of ACLINT MSWI and ACLINT SSWI devices
+ *** One MSWI/SSWI pair may be used for all harts, or multiple MSWI/SSWI
+pairs may be used with multiple topological groups of harts
+ *** Only wired interrupts are supported
+ *** Both M-mode and S-mode IPIs are supported
+ *** Virtualization is not supported
+ ** Zero, one, or more AIA APLIC devices plus per-hart AIA IMSIC devices
+ *** Both wired and MSI external interrupts are supported
+ *** Both M-mode and S-mode IPIs are supported via IMSICs
+ *** Virtualization is supported
+ *** Zero APLICs if there are no wired interrupts and only MSIs

==== System Peripherals
* UART/Serial Console
@@ -513,6 +623,11 @@ in the physical RV processor. +
* Logging and/or reporting of errors can be masked. +
* PCIe AER capability is required. +

+==== Interrupt Controller, Software Interrupt, and Timer Requirements
+ * For Timer support, ACLINT MTIMER devices is/are Required
+ * For Interrupt Controller and Software Interrupt support, the following one choice is Required
+ - Zero, one, or more AIA APLIC devices plus per-hart AIA IMSIC devices
+
// M Platform
== M Platform

--
2.19.0.windows.1


[PATCH v2 0/2] Interrupt Controller Spec

Abner Chang
 

From: Abner Chang <abner.chang@...>

In V2:
- Update Interrupt Controller table in platform spec.
- Add comma before Abner Chang in the contributors list.

In V1:
Initial version of Interrupt Controller, Software Interrupt,
and Timer Requirements. This patch combines the text sent out
by Kumar and the patch Abner sent previously.

Abner Chang (2):
riscv-platform-spec: Interrupt Controller
contributors: Add Abner as contributor

contributors.adoc | 3 +-
riscv-platform-spec.adoc | 125 +++++++++++++++++++++++++++++++++++++--
2 files changed, 122 insertions(+), 6 deletions(-)

--
2.19.0.windows.1


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

atishp@...
 

On Thu, 2021-07-01 at 22:20 +0530, Mayuresh Chitale wrote:
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
MCFG table was not referenced earlier.

+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.
+
UC is not present in abbreviation section. Moreover, PMA + PBMT seems
bit ambiguous to me. It wouldn't hurt to be more verbose here.

+====== 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. 
same comment as above.

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
/s/No_snoop/No Snoop ?

+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 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
Apart from the above nit comments, looks good to me.

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

--
Regards,
Atish


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






701 - 720 of 1847