|
[PATCH] UEFI: Add RISCV_EFI_BOOT_PROTOCOL requirement
Sunil V L
RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL.
This protocol is required to communicate the boot hart ID from firmware to the bootloader/kernel. This protocol specification is maintained by RVI outside of the UEFI forum. The latest specification is available at https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf Signed-off-by: Sunil V L <sunilvl@...> --- riscv-platform-spec.adoc | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 6264ab8..a7f5d92 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -556,6 +556,17 @@ in SBI PMU extensions. the requirements in this section. ==== Firmware +===== UEFI Protocol Support +The UEFI protocols listed below are required to be implemented in addition to +the requirements in EBBR. + +.Additional UEFI Protocols +[cols="3,1,2", width=95%, align="center", options="header"] +|=== +|Protocol | UEFI Section | Note +|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID +|=== + ===== Storage and Partitioning - GPT partitioning required for shared storage. - MBR support is not required. @@ -675,11 +686,12 @@ newer with HW-Reduced ACPI model. The UEFI protocols listed below are required to be implemented. .Additional UEFI Protocols -[cols="3,1,1", width=95%, align="center", options="header"] +[cols="3,1,2", width=95%, align="center", options="header"] |=== |Protocol | UEFI Section | Note |EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL | 14 | For PCIe support |EFI_PCI_IO_PROTOCOL | 14.4 | For PCIe support +|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID |=== ==== Hardware Discovery Mechanisms @@ -1102,3 +1114,4 @@ implementations should aim for supporting at least 16 PMP regions. * [[[spec_riscv_watchdog,22]]] link:https://github.com/riscv-non-isa/riscv-watchdog/blob/main/riscv-watchdog.adoc[RISC-V Watchdog Timer Specification], Version: Version 1.0 * [[[spec_riscv_platform_policy,23]]] link:https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY/edit[RISC-V Platform Platform Policy], Version: 1.0 * [[[spec_pcie_sig,24]]] link:https://pcisig.com/specifications[PCIe Base Specification Revision], Revision: 1.1 +* [[[spec_riscv_uefi,25]]] link:https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf[RISC-V UEFI Protocol Specification], Version: 1.0-rc2 -- 2.25.1
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
atishp@...
On Thu, Jan 27, 2022 at 12:57 AM Heinrich Schuchardt <heinrich.schuchardt@...> wrote: On 1/27/22 09:33, atishp@... wrote: There was no need for any extension specific return value yet. I doubt if we will need one in the future. To reduce ambiguity, how about this change: "Returns 0 if the given SBI extension ID (EID) is not available, or 1 if it is available unless defined as any other non-zero value by the implementation." This aligns with what Andrew suggested and is compatible with all the existing implementations. I would prefer if the specification would provide extension specific
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Heinrich Schuchardt
On 1/27/22 09:33, atishp@... wrote:
On Tue, Jan 18, 2022 at 2:46 PM Andrew Waterman <andrew@... <mailto:andrew@...>> wrote:Why should the value be implementation specific and not extension specific? I would prefer if the specification would provide extension specific unique return values instead of introducing ambiguity about possible return values. This also allows us to define further return values per extension if needed in future. But currently all of these values can be defined as 1. We just have to add this value 1 to each extension description. Best regards Heinrich Jonathan
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
atishp@...
On Tue, Jan 18, 2022 at 2:46 PM Andrew Waterman <andrew@...> wrote:
Sounds good to me as well. I will make the change.
|
|
|
|
Introduction Update and OS-A Motivation
Aaron Durbin
Hi All, I submitted a pull request to the platform spec repo: https://github.com/riscv/riscv-platform-specs/pull/75 This is definitely a WIP, but I wanted to start the conversation. Much of the language is cribbed from the platform policy doc itself as I think that was well written and provides the context for the platforms themselves. Note: there are definitely some other reorganizations required, I think, to make the first part flow better. I was thinking that under the OS-A part specifically we expand further, but I put in a quick blurb to describe that direction. All that said, there are definitely pieces in the spec that read more like a one pager for product requirements. It's not abundantly clear to me what the platform specs are supposed to be in the end. Are they hardware product requirements or a target of expectations for a software environment? I know this question is a much broader topic, but it's something we should agree on. My personal opinion is that we focus on bootstrapping the software ecosystem so that off the shelf OSes can be used for system evaluation. From there, and once a richer hardware ecosystem is realized, I can definitely see the platform specs turning more into a hardware product requirements. Lastly, feel free to pepper me with suggestions on how to take the language. I can play secretary on everyone's behalf. Thanks. -Aaron
|
|
|
|
Re: Specifying Cache Granule Size in Platform
Are we or will we be using any benchmarks here? I worry that this is based on experience. Workloads have evolved. Things like traversing workloads (hadoop, cpu encrypt, cpu compress, ...) and sparse workloads (uniq query hash tables, sparse matrices, ...) have many times become more important than the principles of locality. I know we are just starting the perf modeling sig but I suggest we will have to settle on a tool we use to identify issues and mark progress over an agreed set of cache/memory configurations. Of course vendors will test on their hardware. While I understand some basics are just needed, when I hear David talk in his comments I suggest we pick ways to grade ourselves and our choices objectively. In my experience getting these things wrong (locks and latches, cache prefetch, cache fragmentation, cache occupancy, etc.) can easily exceed any benefit we get from instruction architecture improvements. These issues cross many group boundaries. Mark
On Mon, Jan 24, 2022 at 10:28 PM David Kruckemyer <dkruckemyer@...> wrote:
|
|
|
|
Re: Specifying Cache Granule Size in Platform
David Kruckemyer
Hi all, A few comments to add on here: - The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block size for Zicboz instructions, and another for Zicbom instructions (and maybe even another for Zicbop instructions, too). - v1.0 of these specs requires that the block size is fixed across the system - The block size is discoverable via to-be-specified standard discovery structure, but the thinking was that software at all privilege levels could access that information (though such information may be virtualized as necessary) - Though not formally specified (yet), the working definition of "cache block" is the NAPOT region that a CMO instruction operates on, independent of the implemented cache line size; so in some sense, a cache block abstracts away cache lines. As I mentioned, that's a working definition, and there are of course issues that arise when there is a mismatch between the abstract block size and the actual line size (and one of the items on the to-do list for the CMO TG is to address some of these issues). Anyway, the key takeaway is that the terminology for block, line, granule, etc. should be well-defined, and the platform group and the CMO TG should align. - Note that there is often a close relationship between the cache line size and the coherence granule size (I know, introducing a new term here), and though this may not be the right forum for the discussion, the architecture needs to understand whether different line sizes implies different coherence granule sizes (or more generally, whether one implies constraints on the other). - Another related issue is LR/SC reservation set size. - Philosophical thought: Trap and emulate allows one to commit a bunch of sins, and it may be pragmatic for certain platform definitions to be performant only for "common" implementations and to just be compatible for other implementations. For example, the block size for CBO.ZERO could be defined to be 64B in a platform. On harts that support 64B zero writes, executing CBO.ZERO performs the operation without a trap; on harts that do not, executing CBO.ZERO traps to a handler that performs the equivalent of the 64B zero write. (The trapping behavior can be controlled by xenvcfg.CBZE.) That was a bit more than I expected to write. Hope some of it is helpful.... Cheers, David
On Mon, Jan 24, 2022 at 7:15 PM Aaron Durbin <adurbin@...> wrote:
|
|
|
|
Specifying Cache Granule Size in Platform
Aaron Durbin
Hi All, During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to provide a basis for discussion. Philip indicated cbo.zero would be the main target for specifying the size. If we went down that path, I think it'd be important to also specify the size for cbo.flush as well. If the granule size is only determined at run time there inherently are solutions that need to be constructed to deal with a number of scenarios. Some cases to think about: 1. Userland drivers 2. VM migration 3. object layout in memory for optimization purposes 4. inconsistent granule size within different harts in the system Ved brought up how it's important to interrogate the cache hierarchy for these attributes, and that it's important to know on a per-hart basis what cache granule size it deals with. We can certainly engineer solutions for the various cases in either scenario, but I think the discussion around specifying the granule size should be in understanding how we'd deal with those solutions going forward. And please offer any other scenarios that may come to mind. Lastly, I apologize if I missed any particular commentary on this subject. Thanks. -Aaron
|
|
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Greg Favor
On Mon, Jan 24, 2022 at 10:32 AM Michael Frank <Michael.Frank@...> wrote:
The RVA22S64 ISA profile will provide all that detail. An 2022 OS-A platform spec will simply mandate the RVA22S64 profile. Greg
|
|
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Michael Frank
Hi Greg,
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each profile?
Michael
😄
Michael
From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...>
Sent: Monday, January 24, 2022 7:59:22 AM To: tech-unixplatformspec <tech-unixplatformspec@...> Cc: Greg Favor <gfavor@...> Subject: Re: [RISC-V] [tech-unixplatformspec] Mandating of RVA22 S and U ISA Profiles in OS-A platform specs [EXTERNAL EMAIL] On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> wrote:
> Recently a PR was sent out to remove U and VU mode standardization from the That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate.
> *The current version of this platform spec targets the standardization of I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec). One can view the text as also truly a normative part of the
spec, or simply as descriptive overview of the scope of the normative spec.
In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality.
Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality.
The first portion is explicit in the privileged specification, and the But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality.
But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec. If one views the scope statement as a normative mandate of the
platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment.
Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality. Since the target of the platform is to support hardware/software interoperability with binary distros, those
distros (e.g. Linux) contain U/VU-mode code. Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes. Saying that the platform spec only standardizes the S-mode interface can be misleading to readers.
It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality.
Greg
To reduce fraud or cyber-crime risks, Arteris IP will never instruct you to change wire payment instructions or bank account details using email or fax. If you receive such an email or fax appearing to be from Arteris IP, please call your Arteris IP’s contact to verify. Please do not verify by email.
|
|
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Greg Favor
On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> wrote: > Recently a PR was sent out to remove U and VU mode standardization from the That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate. > *The current version of this platform spec targets the standardization of I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec). One can view the text as also truly a normative part of the spec, or simply as descriptive overview of the scope of the normative spec. In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality. Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality. The first portion is explicit in the privileged specification, and the But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality. But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec. If one views the scope statement as a normative mandate of the platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment. Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality. Since the target of the platform is to support hardware/software interoperability with binary distros, those distros (e.g. Linux) contain U/VU-mode code. Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes. Saying that the platform spec only standardizes the S-mode interface can be misleading to readers. It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality. Greg
|
|
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Darius Rad
On Sat, Jan 22, 2022 at 12:15:01PM -0800, Greg Favor wrote:
Could you explain in what way you think it is wrong? I brought this issue up with Krste and Andrew (especially since this alsoI disagree; I think the parenthetical comment is unnecessary in the normative text. The first portion is explicit in the privileged specification, and the second portion, and noted, is implied by the extensions mandated for S mode. Adding this comment as normative text muddies the scope of the specification: it is standardizing the S-mode interface only. Period. // darius
|
|
|
|
Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Greg Favor
All, Recently a PR was sent out to remove U and VU mode standardization from the platform spec scope. Which is sort of right and sort of wrong. I brought this issue up with Krste and Andrew (especially since this also relates with the coming RVA Profiles). In short, after significant discussion, the following can be said:
So I suggest that the change to the platform spec should be something like:
Greg
|
|
|
|
Next Platform HSC Meeting on Mon Jan 24th 2022 8AM PST
Hi All,
The next platform HSC meeting is scheduled on Mon Jan 24th 2022 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/1fVM2loPrbBotyhiC5JNt0NqkbD3MkRu5-Rr23BCMzo4/edit#slide=id.g1044423f839_0_0 Meeting info Zoom meeting: https://zoom.us/j/2786028446 Passcode: 901897 Or iPhone one-tap : US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 278 602 8446 International numbers available: https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_ Regards Kumar
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
merle w
Thank you for your reply
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
atishp@...
On Thu, Jan 20, 2022 at 6:23 PM <merlew4n6@...> wrote:
That won't be required as the specification clearly states that "SBI extensions as whole are optional but they shall not be partially implemented. If sbi_probe_extension() signals that an extension is available, all functions present in the SBI version reported by sbi_get_spec_version() must conform to that version of the SBI specification."
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
merle w
3.4. Function: Probe SBI extension (FID #3)
struct sbiret sbi_probe_extension(long extension_id);
Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero
value if it is available. Do we need to add more fine-grained detection to check if a certain funcid is available
|
|
|
|
Re: [PATCH] Remove stoptime requirement
Hi Paul, Can you send a PR please?
Regards Kumar
From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Paul Donahue
Sent: Wednesday, January 12, 2022 11:49 AM To: tech-unixplatformspec <tech-unixplatformspec@...> Subject: [RISC-V] [tech-unixplatformspec] [PATCH] Remove stoptime requirement
Signed-off-by: Paul Donahue <pdonahue@...> ---
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Andrew Waterman
On Wed, Jan 19, 2022 at 3:10 AM Anup Patel <apatel@...> wrote: Hi Andrew, Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).
|
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Hi Andrew,
On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote: I mostly agree with your suggestion considering the fact that we have very few (or none) RV32 Linux (or RichOS) capable systems. I would also like to correct my previous comment about the RV32 limitation. The RV32 limitation only affects SBI HSM and does not affect any other SBI extension (including SBI RFENCE) because SBI RFENCE calls take virtual address as "unsigned long" parameter. In other words, on a RV32 system the SBI HSM start and suspend calls will need a physical address within the 4GB address range. Regards, Anup I agree with this suggestion. We got this question multiple times in
|
|
|