|
Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension
Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道： On 6/28/21 8:39 AM, Abner Chang wrote: That's true. On the server platform, RTC doesn't work alone. It incorporates with BMC to get the time information because only BMC is alive even when the system is powered off. The system only syncs up the time settings from BMC when every time the system boots. GetTime function is used by the firmware or the pre-OS EFI applications. SetTIme is used when the firmware sync up the time with BMC or the server deployment. RTC is the media to keep the time information, how to use RTC is implementation-specific. Abner
|
|
|
|
Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension
On 6/28/21 8:39 AM, Abner Chang wrote:
The way that UEFI reports local time zones is unsatisfactory: There is an offset to UTC and a daylight savings flag but this does not allow to derive on which day daylight saving switches (you could be on the southern or on the northern hemisphere) nor the daylight savings offset which historically has been one hour or two hours. Furthermore many RTC chips do not store timezone related information. EDK II stores it in UEFI variables. There is no handling of daylight savings switches in EDK II. With this background allowing anything else but UTC just creates ambiguity. This paragraph is self-contradictory: It requires RTC to facilitate "RTC wake up" but allows SetWakeupTime() to report EFI_UNSUPPORTED. Best regards Heinrich + |
|
|
|
Re: [PATCH 2/2] contributors: Add Abner as contributor
Sunil V L
Hi Abner,
On Sat, Jun 26, 2021 at 10:16:01PM +0800, Abner Chang wrote: From: Abner Chang <abner.chang@...>"," is required before your name here. +Abner Chang |
|
|
|
Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension
Jonathan Behrens <behrensj@...> 於 2021年6月25日 週五 下午11:11寫道：
That depends on how do you implement GetTime/SetTime functions for the platform. You can always not returning EFI_UNSPECIFIED_TIMEZONE in the implementation and just return the offset to UTC for the local time. Abner
|
|
|
|
[PATCH 2/2] contributors: Add Abner as contributor
From: Abner Chang <abner.chang@...>
Signed-off-by: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <abner.chang@...> --- contributors.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/contributors.adoc b/contributors.adoc index a1ea5ef..57ac8bc 100644 --- a/contributors.adoc +++ b/contributors.adoc @@ -30,6 +30,7 @@ Sunil V L, Rahul Pathak, Mayuresh Chitale, 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 1/2] riscv-platform-spec: Interrupt Controller
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 | 78 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 73 insertions(+), 5 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 87ab7f8..8a1a45f 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,67 @@ 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, +*AIA* (spec link ?) 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 three 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 Platforms|NA|NA|NA|PLIC|PLIC|PLIC|MSWI + +(CLINT)|SBI IPI|SBI IPI|MTIMER + +(CLINT)|SBI Timer|SBI Timer +|Platfomrs with only wired IRQs|NA|NA|NA|APLIC M-level Domain|APLIC S-level Domain| +APLIC S-level Domain|MSWI|SSWI|SBI IPI|MTIMER|Priv SSTC|Priv SSTC +|Platfomrs with MSIs and wired IRQs|IMSIC M-level|IMSIC S-level|IMSIC VS-level| +APLIC M-level Domain|APLIC S-level Domain|APLIC S-level Domain|IMSIC M-level| +IMSIC S-level|IMSIC VS-level + +OR + +SBI IPI|MTIMER|Priv SSTC|Priv SSTC +|======= + +* 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 +576,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 |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
OK agreed. We can remove the ASID requirement all together.
Regards Kumar From: Greg Favor <gfavor@...>
Sent: Friday, June 25, 2021 8:05 PM To: Andrew Waterman <andrew@...> Cc: Jonathan Behrens <behrensj@...>; Kumar Sankaran <ksankaran@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
On Fri, Jun 25, 2021 at 8:00 PM Andrew Waterman <andrew@...> wrote:
Recent platform discussion about this question concluded the same.
Greg
|
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Greg Favor
On Fri, Jun 25, 2021 at 8:00 PM Andrew Waterman <andrew@...> wrote:
Recent platform discussion about this question concluded the same. Greg |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
andrew@...
On Fri, Jun 25, 2021 at 4:31 PM Jonathan Behrens <behrensj@...> wrote:
Significant HW cost in TLBs. My take is we should avoid imposing this requirement altogether. Kernel software needs to support the no-ASID case, anyway, so we aren’t simplifying software by imposing this requirement.
|
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Jonathan Behrens <behrensj@...>
Requiring ASID support without specifying the number of bits means that even 1-bit ASIDs would be allowed, even though they'd be essentially useless. That said, I don't have a strong feeling about a particular number of bits to pick. Some software designs can get by on 4 bits, while others may benefit from 8 or even 16. Is there anyone who would object to mandating the full 16 ASID bits for the Server Extension of the OS-A platform? I'm a software person so I really don't have a good sense of whether more bits would meaningfully increase costs/complexity. Jonathan On Fri, Jun 25, 2021 at 4:55 PM Kumar Sankaran <ksankaran@...> wrote:
|
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Hi Jonathan, Regarding ASID and VMID support, we are mandating those only for the Server Extension within the OS-A platform and not for OS-A platform base. We could consider a minimum of 12-bits for the ASID support for the server extension, but then most server platforms would in reality only implement 4 bits of ASID. So simply mandating ASID support without any additional requirement seemed to be the best approach. Is there any particular number of ASID bits you suggest for the server extension? Same for the VMID as well.
Regarding your second comment, yes, I agree that implementations shouldn’t be allowed to “fake” ASID support by clearing the entire TLB when the ASID changes. This will be a big performance penalty. Having said that, the approach the platform spec takes is to have a minimal set of features for hardware and software compatibility without mandating any performance requirements. So we can add the below line as an Informational or Application Note below the requirement. If you have an alternative wording for this line, feel free to send that over.
Regards Kumar From: Jonathan Behrens <behrensj@...>
Sent: Friday, June 25, 2021 9:18 AM To: Kumar Sankaran <ksankaran@...> Cc: tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Is this supposed to include more detail than just "ASID support" and "VMID support"? Not sure if those are just placeholder section headings for now, but I'd expect to at least see a requirement of how many bits are required for each.
Also not entirely sure how to specify it, but it would be really nice if implementations weren't allowed to have "fake" ASID support by just clearing the TLB whenever the ASID changes. That's the strategy QEMU uses (at least the last time I checked) and it has the impact of leading to worse performance than not having ASIDs at all.
Jonathan
On Thu, Jun 24, 2021 at 8:01 PM Kumar Sankaran via lists.riscv.org <ksankaran=ventanamicro.com@...> wrote:
|
|
|
|
Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST
Hi All,
The next platform HSC meeting is scheduled on Mon Jun 28th at 8AM PST. Here are the details: Agenda and minutes kept on the github wiki: https://github.com/riscv/riscv-platform-specs/wiki Here are the slides: https://docs.google.com/presentation/d/1BnCDjSxAFqpRlEbyQ4zOrGqoOEp0aQzzoJgTxgDygLk/edit#slide=id.ge09029d4aa_0_0 Meeting info Zoom meeting: https://zoom.us/j/2786028446 Passcode: 901897 Or iPhone one-tap : US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 278 602 8446 International numbers available: https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_ Regards Kumar |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Jonathan Behrens <behrensj@...>
Is this supposed to include more detail than just "ASID support" and "VMID support"? Not sure if those are just placeholder section headings for now, but I'd expect to at least see a requirement of how many bits are required for each. Also not entirely sure how to specify it, but it would be really nice if implementations weren't allowed to have "fake" ASID support by just clearing the TLB whenever the ASID changes. That's the strategy QEMU uses (at least the last time I checked) and it has the impact of leading to worse performance than not having ASIDs at all. Jonathan On Thu, Jun 24, 2021 at 8:01 PM Kumar Sankaran via lists.riscv.org <ksankaran=ventanamicro.com@...> wrote: This patch adds the following |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Greg Favor
On Fri, Jun 25, 2021 at 5:22 AM Philipp Tomsich <ptomsich@...> wrote:
ARM went through this issue with the variety of CPU designs that people have done (both outside and inside ARM). In particular, as people went to larger and/or more power-efficient L1 caches, they implemented VIPT caches. Which exposes VA aliasing to software. So either software has to manage cache consistency, or hardware has to (i.e hardware has to make the VIPT cache appear to behave like a PIPT cache). That's non-trivial hardware, but not unreasonable. The result is that while ARM architecture allows VIVT, VIPT, and PIPT caches, in A class cores everything has moved to caches that appear to be PIPT while many actually are VIPT designs. One can say that RVWMO compliance implies a requirement that caches appear to behave like PIPT caches. But, given the growing use of VIPT caches, it's worth half a sentence to make clear the implications of RVWMO.
Agreed. I'll come up with some better words for Kumar to use.
People tend to presume this in OS/A-class systems, but yes this should be explicitly stated. Greg |
|
|
|
Re: [PATCH 1/2] riscv-platform-spec: Real-time Clock to server extension
Jonathan Behrens <behrensj@...>
Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require that time is always UTC? Jonathan From: Abner Chang <abner.chang@...> |
|
|
|
[PATCH 2/2] contributors: Add Abner as contributor
From: Abner Chang <abner.chang@...>
Signed-off-by: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <abner.chang@...> --- contributors.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/contributors.adoc b/contributors.adoc index a1ea5ef..57ac8bc 100644 --- a/contributors.adoc +++ b/contributors.adoc @@ -30,6 +30,7 @@ Sunil V L, Rahul Pathak, Mayuresh Chitale, 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 1/2] riscv-platform-spec: Real-time Clock to server extension
From: Abner Chang <abner.chang@...>
RTC (Real-time Clock) Real-time clock is the server basic system peripheral to provide the real date/time information for server to manage the system date, time and time zones settings for different regions through the local POST time firmware utility, NTP or the remote management such as Redfish. Signed-off-by: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <abner.chang@...> --- riscv-platform-spec.adoc | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 87ea6d5..d611d69 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -442,9 +442,9 @@ The UEFI run time services listed below are required to be implemented. |SetVariable | 8.2 | A dedicated storage for firmware is required so that there is no conflict in access by both firmware and the OS. |QueryVariableInfo | 8.2 | -|GetTime | 8.3 | RTC Access by the OS -|SetTime | 8.3 | If it is not possible to set the RTC, -the SetTime() can return an error. +|GetTime | 8.3 | RTC Access by the OS and firmware +|SetTime | 8.3 | RTC configured by the OS and +firmware |GetWakeupTime | 8.3 | Interface is required to be implemented but it can return EFI_UNSUPPORTED. |SetWakeupTime | 8.3 | Interface is required to be @@ -469,6 +469,17 @@ https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension. ** Platforms are required to delegate the supervisor timer interrupt to 'S' mode. If the 'H' extension is implemented then the platforms are required to delegate the virtual supervisor timer interrupt to 'VS' mode. + +* Real-time Clock (RTC) +The Real-time clock must be provided to the server extension platform to +facilitate the time management (Date, time and the time zone) and RTC wake up +when the server is in the power down state for the server manageability. +The GetTime()and SetTime() UEFI runtime services must be implemented by +firmware to incorporate with RTC and flexibly support RTC use cases. +GetWakeupTime() and SetWakeupTime() UEFI runtime services are required to be +implemented but it can return EFI_UNSUPPORTED if the wake up from RTC is not +supported. + * PCI-E ==== Secure Boot -- 2.19.0.windows.1 |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Philipp Tomsich
On Fri, Jun 25, 2021 at 2:01 PM Daniel Lustig <dlustig@...> wrote: On 6/25/2021 4:04 AM, Kumar Sankaran wrote: The intent seems to be that caches shall appear (to software) to be non-aliasing. In any case, what's wrong with VIPT caches? Depends on the internal organisation of a VIPT cache (and its size/number of index bits)... The requirement clearly is that the cache appears to be non-aliasing, by whatever design choices. A simple rewording of the original statement to this effect (instead of referencing PIPT) should address this. > - Memory accesses by I/O masters can be coherent or non-coherent with |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Daniel Lustig
On 6/25/2021 4:04 AM, Kumar Sankaran wrote:
Hi Andrew,I agree with Andrew. What does it mean for caches to appear to software in any particular way? Unless you're talking about something like CMOs, aren't caches entirely transparent to software? In any case, what's wrong with VIPT caches? - Memory accesses by I/O masters can be coherent or non-coherent withSince we're aiming for clarity here, if we do keep this wording (and I'm not saying we should), can we also clarify whether this implies anything about the coherence PMAs? IIUC the PMAs represent the harts' perspective on memory, so those would generally (or possibly always in the OS-A platform?) mark main memory regions as coherent, even if external devices may access that same memory non-coherently? Dan Regards |
|
|
|
Re: [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
Hi Andrew, Agree with your comment on the RVWMO memory model requirement. Since this requirement is for the OS-A platform, providing an additional level of clarity will help since all implementations will be having a cache sub-system. So how about the below wording? - All harts must adhere to the RVWMO memory model. Consequently, any hart-related caches must all be hardware coherent with respect to each other, and must appear to software as physically-indexed, physically-tagged (PIPT) caches. - Memory accesses by I/O masters can be coherent or non-coherent with respect to any hart-related caches Regards Kumar From: Andrew Waterman <andrew@...>
Sent: Thursday, June 24, 2021 11:24 PM To: Kumar Sankaran <ksankaran@...> Cc: tech-unixplatformspec@...; Daniel Lustig <dlustig@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH 1/1] Cache Coherency and ASID Requirements for OS-A platform
+ Dan
I'm not sure it makes sense to include the cache coherence requirement--not because we wish to permit incoherent caches, but because it's a constraint specified at the wrong level of abstraction. The fundamental requirement is that the harts adhere to the RVWMO memory model. The concept of caches and the concept of coherence are implementation details. (Yes, in practice, if you have caches, you'll need cache coherence to implement RVWMO, but that doesn't mean it should be in a list of requirements.)
On Thu, Jun 24, 2021 at 7:00 PM Kumar Sankaran <ksankaran@...> wrote:
|
|
|