Date   

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

Heinrich Schuchardt
 

On 6/28/21 8:39 AM, Abner Chang wrote:


Jonathan Behrens <behrensj@... <mailto:behrensj@...>> 於 2021年6
月25日 週五 下午11:11寫道:

Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require
that time is always UTC?

That depends on how do you implement GetTime/SetTime functions for the
platform.  You can always not returning EFI_UNSPECIFIED_TIMEZONE in the
implementation and just return the offset to UTC for the local time.

Abner
The way that UEFI reports local time zones is unsatisfactory:

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

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

With this background allowing anything else but UTC just creates ambiguity.



Jonathan


On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org
<http://lists.riscv.org> <renba.chang=gmail.com@...
<mailto:gmail.com@...>> wrote:

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

RTC (Real-time Clock)
   Real-time clock is the server basic system peripheral to
provide the real date/time information for server to manage the
system date, time and time zones settings for different regions
through the local POST time firmware utility, NTP or the remote
management such as Redfish.

Signed-off-by: Abner Chang <renba.chang@...
<mailto:renba.chang@...>>
Signed-off-by: Abner Chang <abner.chang@...
<mailto:abner.chang@...>>
---
 riscv-platform-spec.adoc | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..d611d69 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -442,9 +442,9 @@ The UEFI run time services listed below are
required to be implemented.
 |SetVariable               | 8.2        | A dedicated storage
for firmware is
 required so that there is no conflict in access by both
firmware and the OS.
 |QueryVariableInfo         | 8.2        |
-|GetTime                   | 8.3        | RTC Access by the OS
-|SetTime                   | 8.3        | If it is not possible
to set the RTC,
-the SetTime() can return an error.
+|GetTime                   | 8.3        | RTC Access by the OS
and firmware
+|SetTime                   | 8.3        | RTC configured by the
OS and
+firmware
 |GetWakeupTime             | 8.3        | Interface is
required to be
 implemented but it can return EFI_UNSUPPORTED.
 |SetWakeupTime             | 8.3        | Interface is
required to be
@@ -469,6 +469,17 @@
https://lists.riscv.org/g/tech-privileged/message/404[Sstc]
<https://lists.riscv.org/g/tech-privileged/message/404%5BSstc%5D> extension.
 ** Platforms are required to delegate the supervisor timer
interrupt to 'S'
 mode. If the 'H' extension is implemented then the platforms
are required to
 delegate the virtual supervisor timer interrupt to 'VS' mode.
+
+* Real-time Clock (RTC)
+The Real-time clock must be provided to the server extension
platform to
+facilitate the time management (Date, time and the time zone)
and RTC wake up
+when the server is in the power down state for the server
manageability.
+The GetTime()and SetTime() UEFI runtime services must be
implemented by
+firmware to incorporate with RTC and flexibly support RTC use
cases.
+GetWakeupTime() and SetWakeupTime() UEFI runtime services are
required to be
+implemented but it can return EFI_UNSUPPORTED if the wake up
from RTC is not
+supported.
This paragraph is self-contradictory:

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

Best regards

Heinrich

+
 * PCI-E

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


Re: [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@...>

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
"," is required before your name here.

+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






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

Abner Chang
 



Jonathan Behrens <behrensj@...> 於 2021年6月25日 週五 下午11:11寫道:
Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require that time is always UTC?
That depends on how do you implement GetTime/SetTime functions for the platform.  You can always not returning EFI_UNSPECIFIED_TIMEZONE in the implementation and just return the offset to UTC for the local time.

Abner


Jonathan


On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:
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







[PATCH 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 | 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

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

Kumar Sankaran
 

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:

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.

 

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

Recent platform discussion about this question concluded the same.

Greg

 


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

Andrew Waterman
 


On Fri, Jun 25, 2021 at 4:31 PM Jonathan Behrens <behrensj@...> wrote:
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.

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.



Jonathan

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

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:

This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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] 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:

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:

This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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] Cache Coherency and ASID Requirements for OS-A platform

Kumar Sankaran
 

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:

This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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





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

Kumar Sankaran
 

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
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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] Cache Coherency and ASID Requirements for OS-A platform

Greg Favor
 

On Fri, Jun 25, 2021 at 5:22 AM Philipp Tomsich <ptomsich@...> wrote:
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?

The intent seems to be that caches shall appear (to software) to be non-aliasing.

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

Agreed.  I'll come up with some better words for Kumar to use.
 
 
> - Memory accesses by I/O masters can be coherent or non-coherent with
> respect to any hart-related caches

Since 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?

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


On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:
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







[PATCH 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 | 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

Abner Chang
 

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

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?

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
> respect to any hart-related caches

Since 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
>
> 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:
>
> This patch adds the following
> Cache coherency and ASID requirements
> Interrupt Controller and PMU chapter sub-sections for OS-A base and
> Server Extension
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 87ea6d5..b985f50 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
> +
> +==== PMU
>
>  ==== Debug
>  The OS-A base platform requirements are -
> @@ -287,10 +291,12 @@ 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
> +- ASID support
> +- VMID support
> +
> +==== PMU
>
>  ==== Debug
>  The OS-A server platform requirements are all of the base above plus:
> @@ -305,6 +311,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
>






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,

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.
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 with
respect to any hart-related caches
Since 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

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:

This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

==== Debug
The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

==== Debug
The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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


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

Kumar Sankaran
 

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:

This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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] Cache Coherency and ASID Requirements for OS-A platform

Andrew Waterman
 

+ 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:
This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
Server Extension

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -88,8 +88,12 @@ 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 HART related caches must be hardware coherent 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 the HART related caches
+
+==== PMU

 ==== Debug
 The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ 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
+- ASID support
+- VMID support
+
+==== PMU

 ==== Debug
 The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,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





721 - 740 of 1836