|
[PATCH 1/4] Additional requirements for H-extension
To have a meaningful H-extension support, both OS/A-base and
OS/A-server platforms must comply with additional requirements for H-extension. Signed-off-by: Anup Patel <anup.patel@...> --- riscv-platform-spec.adoc | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index a24281f..ce34768 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -120,6 +120,12 @@ The M platform has the following extensions: values.) ** Platforms is allowed to operate only in little-endian mode i.e. implementations must hardwire the mstatus.MBE field to 0. +** If H-extension is implemented then the OS-A platform must comply with + following additional requirements: +*** Upon guest page faults taken into HS-mode, the `htval` CSR must provide + the guest physcial address right shifted by 2. +*** Upon guest page faults taken into M-mode, the `mtval2` CSR must provide + the guest physcial address right shifted by 2. [sidebar] -- @@ -448,9 +454,13 @@ base with the additional requirements as below. ==== Architecture The platforms which conform to server extension are required to implement + -- RV64 support -- RISC-V H ISA extension -- VMID support +* RV64 support +* RISC-V ISA H-extension with following additional requirements: +** VMID support +** Upon load/store/AMO exceptions taken into HS-mode, the `htinst` CSR must + provide transformed standard instruction. +** Upon load/store/AMO exceptions taken into M-mode, the `mtinst` CSR must + provide transformed standard instruction. ==== PMU -- 2.25.1 |
|
|
|
Next Platform HSC Meeting on Mon Jul 26th 2021 8AM PST
Hi All,
The next platform HSC meeting is scheduled on Mon July 26th at 8AM PST. Here are the details: Agenda and minutes kept on the github wiki: https://github.com/riscv/riscv-platform-specs/wiki Here are the slides: https://docs.google.com/presentation/d/192BCGgUcO4xuVHJGKItnhcP_fcf9IaAME57WUBCYJRI/edit#slide=id.gc525db7f82_0_281 Meeting info Zoom meeting: https://zoom.us/j/2786028446 Passcode: 901897 Or iPhone one-tap : US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 278 602 8446 International numbers available: https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_ Regards Kumar |
|
|
|
[PATCH v2] Add an ISA requirement section
atishp@...
There are few ISA level requirements/strong recommendations that platform
should follow. Create an new subsection to contain all these requirements. Move the user-level requirements from user.doc to here as well. Signed-off-by: Atish Patra <atish.patra@...> --- Makefile | 3 +-- riscv-platform-spec.adoc | 24 ++++++++++++++++++++---- user-level.adoc | 17 ----------------- 3 files changed, 21 insertions(+), 23 deletions(-) delete mode 100644 user-level.adoc diff --git a/Makefile b/Makefile index 9556ace700d5..48e8fe9883ed 100644 --- a/Makefile +++ b/Makefile @@ -7,8 +7,7 @@ DITAA = ditaa IMAGES = pcie-topology.png PLATFORM_SPEC = riscv-platform-spec PANDOC = pandoc -PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \ - user-level.adoc +PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc # Build the platform spec in several formats all: $(IMAGES) $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 394304bd6778..e9b295b9802d 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -108,15 +108,31 @@ The M platform has the following extensions: // Base feature set for OS-A Platform === Base ==== Architecture -* ISA Profile +* ISA Requirements ** The OS-A platform is required to comply with the RVA22 profile. -* Cache Coherency +** Within main-memory regions, aligned instruction fetch must be atomic, up to + the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word + is stored with the `sw` instruction, then any processor attempts to execute + that word, the processor either fetches the newly stored word, or some previous + value stored to that location. (That is, the fetched instruction is not an + unpredictable value, nor is it a hybrid of the bytes of the old and new + values.) +** Platforms is allowed to operate only in little-endian mode i.e. + implementations must hardwire the mstatus.MBE field to 0. + +[sidebar] +-- +[underline]*_Recommendation_* + +User-mode programs should not execute the `fence.i` instruction. + +-- +* Cache Coherency ** 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 +** Memory accesses by I/O masters can be coherent or non-coherent with respect to all hart-related caches. - ==== PMU The RVA22 profile defines 32 PMU counters out-of-which first three counters are diff --git a/user-level.adoc b/user-level.adoc deleted file mode 100644 index 2742d98acaac..000000000000 --- a/user-level.adoc +++ /dev/null @@ -1,17 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// user-level.adoc: original User Level Platform content -// -// This is material from the very first draft of the spec. -// - -## User-Level Platform - -* Within main-memory regions, aligned instruction fetch must be atomic, up to - the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word - is stored with the `sw` instruction, then any processor attempts to execute - that word, the processor either fetches the newly stored word, or some previous - value stored to that location. (That is, the fetched instruction is not an - unpredictable value, nor is it a hybrid of the bytes of the old and new - values.) - -- 2.31.1 |
|
|
|
Re: [PATCH] Add an ISA requirement section
atishp@...
On Thu, 2021-07-22 at 15:21 -0700, Andrew Waterman wrote:
Makes sense. I will update the patch. Thanks. --coherent Regards, Atish |
|
|
|
Re: [PATCH] Add an ISA requirement section
andrew@...
On Thu, Jul 22, 2021 at 12:12 PM Atish Patra <atish.patra@...> wrote: On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote: The way we are viewing this from the PrivArch side is that the ISA spec lays out the legal options, and in this document, we constrain the optionality. Following that pattern, we should generally only list the new constraints (i.e. indicate what optionality is not valid). However, as a compromise, we could be more verbose in telegraphing the intent of the constraint: Implementations must support little-endianness: i.e., they must not hardwire the mstatus.MBE field to 1.
|
|
|
|
Re: [PATCH] Add an ISA requirement section
atishp@...
On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote:
Thanks for adding this.ok. I will update it. Just a suggestion: Is it better to say what must be supported rather what is not and be more verbose? Something like this: Platforms is allowed to operate only in little-endian mode i.e. implementations must hardwire the mstatus.MBE field to 0. -- Regards, Atish |
|
|
|
Re: [PATCH] Add an ISA requirement section
andrew@...
Thanks for adding this. For systems that support little-endian, the ISA spec already requires that mstatus.MBE be reset to 0. Furthermore, the ISA spec does not permit hardwiring SBE or UBE to a value that MBE does not support. (And of course the reset values of SBE and UBE are immaterial, since they don't affect M-mode software and M-mode software must initialize the rest of mstatus prior to entering S-mode or U-mode.) If we combine all of these facts, we can replace the following sentence Platforms must fully support Little-Endian operation and must come up in this mode of operation after power-on reset with the more precise constraint Implementations must not hardwire the mstatus.MBE field to 1. and we will still obtain the desired result. On Thu, Jul 22, 2021 at 1:00 AM Atish Patra <atish.patra@...> wrote: There are few ISA level requirements/strong recommendations that platform |
|
|
|
[PATCH] Add an ISA requirement section
atishp@...
There are few ISA level requirements/strong recommendations that platform
should follow. Create an new subsection to contain all these requirements. Move the user-level requirements from user.doc to here as well. Signed-off-by: Atish Patra <atish.patra@...> --- riscv-platform-spec.adoc | 11 +++++++++++ user-level.adoc | 17 ----------------- 2 files changed, 11 insertions(+), 17 deletions(-) delete mode 100644 user-level.adoc diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 394304bd6778..1f5b29a0200b 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -115,6 +115,17 @@ The M platform has the following extensions: ** 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. +* ISA Requirements +** Within main-memory regions, aligned instruction fetch must be atomic, up to + the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word + is stored with the `sw` instruction, then any processor attempts to execute + that word, the processor either fetches the newly stored word, or some previous + value stored to that location. (That is, the fetched instruction is not an + unpredictable value, nor is it a hybrid of the bytes of the old and new + values.) +** Platforms must fully support Little-Endian operation and must come +up in this mode of operation after power-on reset. +** User-mode programs should not execute the `fence.i` instruction. ==== PMU diff --git a/user-level.adoc b/user-level.adoc deleted file mode 100644 index 2742d98acaac..000000000000 --- a/user-level.adoc +++ /dev/null @@ -1,17 +0,0 @@ -// SPDX-License-Indentifer: CC-BY-4.0 -// -// user-level.adoc: original User Level Platform content -// -// This is material from the very first draft of the spec. -// - -## User-Level Platform - -* Within main-memory regions, aligned instruction fetch must be atomic, up to - the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word - is stored with the `sw` instruction, then any processor attempts to execute - that word, the processor either fetches the newly stored word, or some previous - value stored to that location. (That is, the fetched instruction is not an - unpredictable value, nor is it a hybrid of the bytes of the old and new - values.) - -- 2.31.1 |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Fri, Jul 16, 2021 at 10:32 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
Lastly, before I shut up, ... A key point in all this is that memory-mapped registers like MTIME/MTIMECMP will be very uncommon. Most registers, even if logically defined as 64 bits wide, can be readily accessed by software using one or a pair of 32-bit accesses. Especially since those 64-bit registers can only be accessed using 32-bit accesses in RV32 systems, arch definitions of such registers will be motivated to avoid causing complications for RV32 systems where at all possible. Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Fri, Jul 16, 2021 at 10:19 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
In essence, is RV64 going to effectively outlaw ready use of common 32-bit "utility" AMBA bus standards in RV64 systems (especially since there will be a growing number of 64-bit memory-mapped registers defined by extensions this year and going forward)? Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Fri, Jul 16, 2021 at 10:10 PM Greg Favor <gfavor@...> wrote:
Add to the list the popular APB bus standard used by many IPs for access to their memory-mapped registers. It only supports up to 32-bit accesses. Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Fri, Jul 16, 2021 at 9:31 PM Andrew Waterman <andrew@...> wrote:
Common AMBA utility bus standards like the AXI-Lite buses don't support burst accesses - and hence the bus width does set the access width. These bus standards are intended to be simple and sufficient for accessing memory-mapped registers.
It was provided earlier in this email thread - which I'll forward to you in a minute. Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
andrew@...
On Fri, Jul 16, 2021 at 9:12 PM Greg Favor <gfavor@...> wrote:
All RV64 SiFive SoCs support 64-bit accesses to these registers. The ISA spec implies, but does not explicitly state, that this is required: it gives code examples for accessing these registers in RV32. The spec would’ve mentioned RV64 systems that don’t support 64b accesses if it meant to admit that possibility.
While I agree, I view this as an almost orthogonal concern: bus width doesn’t set a limit on access width.
I have to admit I don’t recall that thread. Can you forward along a pointer?
|
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Fri, Jul 16, 2021 at 8:43 PM Anup Patel <Anup.Patel@...> wrote:
While these registers are architecturally 64-bit registers, in many systems they will be accessed over a simple 32-bit bus that doesn't support 64-bit accesses. This will probably be true in many systems (for example some (or maybe most?) SiFive SoCs such as the FU540 SoC). Who wants to spend the hardware on a 2x wide bus for negligible benefit. Plus some common bus standards won't support both 32-bit and 64-bit accesses, which complicates mapping and accessing 32-bit registers over a bus that only supports 64-bit accesses. (Use of a 32-bit bus will tend to be true in both embedded and even high-end systems. In the latter case the main coherent bus may be quite wide and capable of multi-width accesses, but no one wants to impose the complexity of interfacing to that bus onto all the SoC devices that have memory-mapped registers and want to have the simplest possible bus standard to interface to.) The point of what was suggested as a result of the email discussions with Andrew a year ago, is that support for the common case should be required (e.g. 32-bit accesses) and then have a DT property that says 64-bit accesses may also be used by software. Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Both MTIME and MTIMECMP are 64-bit wide registers from device perspective (i.e. from ACLINT specification perspective). The ACLINT specification does not mandate 32-bit or 64-bit accesses for RISC-V HARTs. This means by default software will assume 64-bit accesses on RV64 and 32-bit accesses on RV32. We can certainly have an optional boolean DT property “mtimer,64bit-access-not-supported” which will force software to use 32-bit accesses on RV64 system.
Regards, Anup
From: Josh Scheid <jscheid@...>
On Thu, Jul 15, 2021 at 7:01 PM Greg Favor <gfavor@...> wrote:
The optional 64-bit access option from HW would need to be communicated in discovery/DT.
-Josh |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Josh Scheid
On Thu, Jul 15, 2021 at 7:01 PM Greg Favor <gfavor@...> wrote:
The optional 64-bit access option from HW would need to be communicated in discovery/DT. -Josh |
|
|
|
[PATCH v1 1/1] Server extension: PCIe - AIA requirements
Mayuresh Chitale
This patch adds requirements for mapping PCIe interrupts to AIA.
Signed-off-by: Mayuresh Chitale <mchitale@...> --- riscv-platform-spec.adoc | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 394304b..74d07f8 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -88,6 +88,7 @@ The M platform has the following extensions: |MSI-X | Enhanced Message Signaled Interrupts |INTx | PCIe Legacy Interrupts |PMA | Physical Memory Attributes +|PRT | PCI Routing Table |=== === Specifications @@ -734,8 +735,26 @@ 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 +* Following are the requirements for INTx: +** For each root port in the system, the platform shall map all the INTx +virtual wires to four distinct sources at the APLIC. Each of these sources +shall be configured as Level0 as described in Table 4.2: Encoding of the SM +(Source Mode) field) of the RISC V AIA specification. +** Platform firmware shall implement the _PRT as described in section 6.2.13 of +ACPI Specification to describe the mapping of interrupt pins and the +corresponding interrupt minor identities at the Hart. +** If interrupt generation for correctable/fatal/non-fatal error messages is +enabled via the root error command register of the AER capability and the root +port does not support MSI/MSI-X capability, then the platform is required to +generate an INTx interrupt via APLIC when any of the above error messages is +received by the root port. +* Following are the requirements for MSI: +** As per the RISC V AIA specification since the number 0 is not a valid +interrupt identity, the platform software is required to ensure that MSI data +value assigned to a PCIe function is never 0. For e.g for a PCIe function which +requests 16 MSI vectors the minimum MSI data value assigned by the platform +software can be 0x10 so that the function can use lower 4 bits to assert each +of the 16 vectors. ====== PCIe cache coherency Memory that is cacheable by harts is not kept coherent by hardware when PCIe -- 2.17.1 |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Greg Favor
On Thu, Jul 15, 2021 at 5:03 PM Josh Scheid <jscheid@...> wrote:
Here's the most salient part of a long email thread last year with Andrew about this question (I've annotated the latter part with people's initials to help make clear who is saying what): -------------------------------------------------------------------------------------------- On ... Andrew Waterman <andrew@...> wrote:
AW: I think your interpretation of that sentence is accurate. FWIW, the insufficiently described Linux platform does assume such accesses are legal (more precisely, the various SBI implementations make that assumption). -------------------------------------------------------------------------------------------- On ... David Kruckemyer <dkruckemyer@...> wrote: It appears that OpenSBI supports 32b accesses to the CLINT on an RV64 system (the CLINT is where mtime[cmp] live in an SiFive FU540 SOC.): ===================================================== So, in short, we (the Platform specs) need to now address this issue (as Andrew touched on). The platform spec should say, in some form, that on both RV32 and RV64 platforms the MTIME register may be accessed using a pair of 32-bit accesses - and should be done in the manner shown by the example code in the MTIME register section of the Priv Arch spec. Also, the ACLINT spec should specify that the various registers (including MTIME) are (i.e. must be) accessible on both RV32 and RV64 systems using 32-bit accesses (and may also be accessible using 64-bit accesses on RV64 platforms) Lastly, it seems like all this can just be said in the ACLINT spec. The platform specs will automatically then inherit this as part of using ACLINT (or parts of ACLINT). Greg |
|
|
|
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Josh Scheid
>
The MTIME register is a 64-bit read-write register Is the device required to allow only 64-bit accesses to these registers? Can a device allow 32-bit accesses? Can a device only support 32-bit accesses? If only one size or the other, how will SW know (e.g., in DT)? -Josh |
|
|
|
Re: [PATCH v2 2/3] Remove the old descriptions from user-level.adoc
Greg Favor
On Thu, Jul 15, 2021 at 4:45 PM Kumar Sankaran <ksankaran@...> wrote:
I was already planning to, so definitely yes. Greg |
|
|