Date   

[PATCH 1/1] server extension: PCIe requirements

Mayuresh Chitale
 

This patch adds requirements for PCIe support for the server extension

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 164 insertions(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 4418788..590cf70 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -47,7 +47,21 @@ include::profiles.adoc[]
|RVA22 | RISC-V Application 2022
|EE | Execution Environment
|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
-|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|PCIe | PCI Express
+|ECAM | Enhanced Configuration Access Mechanism
+|BAR | Base Address Register
+|AER | Advanced Error Reporting
+|CRS | Configuration Request Retry Status
+|TLP | Transaction Layer Packet
+|RCIEP | Root Complex Integrated Endpoint
+|RCEC | Root Complex Event Collector
+|PME | Power Management Event
+|MSI | Message Signaled Interrupts
+|MSI-X | Enhanced Message Signaled Interrupts
+|INTx | PCIe Legacy Interrupts
+|PMA | Physical Memory Attributes
+|PBMT | Page Based Memory Types
|===

=== Specifications
@@ -363,7 +377,155 @@ https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension.
** Platforms are required to delegate the supervisor timer interrupt to 'S'
mode. If the 'H' extension is implemented then the platforms are required to
delegate the virtual supervisor timer interrupt to 'VS' mode.
-* PCI-E
+
+===== PCIe
+Platforms are required to support at least PCIe Base Specification Revision 1.1
+footnote:[https://pcisig.com/specifications].
+
+====== PCIe Config Space
+* Platforms shall support access to the PCIe config space via ECAM as described
+in the PCIe Base specification.
+* The entire config space for a single PCIe domain should be accessible via a
+single ECAM I/O region.
+* Platform firmware should implement the MCFG table to allow the operating
+systems to discover the supported PCIe domains and map the ECAM I/O region for
+each domain.
+* Platform software shall configure ECAM I/O regions such that the effective
+memory type (PMA + PBMT) is UC.
+
+====== PCIe Memory Space
+Platforms are required to map PCIe address space directly in the system address
+space and not have any address translation for outbound accesses from harts or
+for inbound accesses to any component in the system address space
+
+* PCIe Outbound Memory +
+PCIe devices and bridges/switches frequently implement BARs which only support
+32-bit addressing or support 64 bit addressing but do not support prefetchable
+memory. To support mapping of such BARs, platforms are required to reserve
+some space below 4G for each root port present in the system.
+
+[sidebar]
+--
+[underline]*_Implementation Note_* +
+Platform software would likely configure these per root port regions such that
+their effective memory type (PMA + PBMT) is UC. Platforms would likely also
+reserve some space above 4G to map BARs that support 64 bit addressing and
+prefetchable memory which could be configured by the platform software as either
+I/O or memory.
+--
+
+* PCIe Inbound Memory +
+For security reasons, platforms must provide a mechanism controlled by M-mode
+software to restrict inbound PCIe accesses from accessing regions of address
+space intended to be accessible only to M-mode software.
+
+[sidebar]
+--
+[underline]*_Implementation Note_* +
+Such an access control mechanism could be analogous to the per-hart PMP
+as described in the RISC-V Privileged Architectures specification.
+--
+
+====== PCIe Interrupts
+* Platforms shall support both INTx and MSI/MSI-x interrupts.
+* Integration with AIA +
+TBD
+
+====== PCIe cache coherency
+PCIe transactions that are not marked as No_snoop and access memory that is
+cacheable by harts, as well as accesses to memory that is noncacheable by
+harts, are I/O Coherent and no software coherency management is needed.
+In contrast, PCIe transactions that are marked as No_snoop and access memory
+that is cacheable by harts, must have coherency managed by software.
+
+====== PCIe Topology
+Platforms are required to implement at least one of the following topologies
+and the components required in that topology.
+
+[ditaa]
+....
+
+ +----------+ +----------+
+ | CPU | | CPU |
+ | | | |
+ +-----|----+ +-----|----+
+ | |
+ | |
+ +-------------|------------+ +-------------|------------+
+ | ROOT | COMPLEX | | ROOT | COMPLEX |
+ | | | |
+ | +------|-------+ | | +------|-------+ |
+ | | Host Bridge | | | | Host Bridge | |
+ | +------|-------+ | | +------|-------+ |
+ | | | | | |
+ | | BUS 0 | | | BUS 0 |
+ | |-------|------| | | +-----|-------+ |
+ | | | | | | ROOT PORT | |
+ | | | | | +-----|-------+ |
+ | +---|---+ +---|---+ | | | |
+ | | RCEIP | | RCEC | | | | PCIe Link |
+ | +-------+ +-------+ | | | |
+ | | +-------------|------------+
+ +--------------------------+ |
+ | BUS 1
+ RCEIP - Root complex integrated endpoint
+ RCEC - Root complex event collector
+....
+
+* Host Bridge +
+Following are the requirements for host bridges:
+
+** Any read or write access by a hart to an ECAM I/O region shall be converted
+by the host bridge into the corresponding PCIe config read or config write
+request.
+** Any read or write access by a hart to a PCIe outbound region shall be
+forwarded by the host bridge to a BAR or prefetch/non-prefetch memory window,
+if the address falls within the region claimed by the BAR or prefetch/
+non-prefetch memory window. Otherwise the host bridge shall return an error.
+
+** Host bridge shall return all 1s in the following cases:
+*** Config read to non existent functions and devices on root bus.
+*** Config reads that receive Unsupported Request response from functions and
+devices on the root bus.
+* Root ports +
+Following are the requirements for root ports.
+** Root ports shall appear as PCI-PCI bridge to software.
+** Root ports shall implement all registers of Type 1 header.
+** Root ports shall implement all capabilities specified in the PCIe Base
+specification for a root port.
+** Root ports shall forward type 1 configuration access when the bus number in
+the TLP is greater than the root port's secondary bus number and less than or
+equal to the root port's subordinate bus number.
+** Root ports shall convert type 1 configuration access to a type 0
+configuration access when bus number in the TLP is equal to the root port's
+secondary bus number.
+** Root ports shall respond to any type 0 configuration accesses it receives.
+** Root ports shall forward memory accesses targeting its prefetch/non-prefetch
+memory windows to downstream components. If address of the transaction does not
+fall within the regions claimed by prefetch/non-prefetch memory windows then
+the root port shall generate a Unsupported Request.
+** Root port requester id or completer id shall be formed using the bdf of the
+root port.
+** The root ports shall support the CRS software visibility.
+** The root port shall implement the AER capability.
+** Root ports shall return all 1s in the following cases:
+*** Config read to non existent functions and devices on secondary bus.
+*** Config reads that receive Unsupported Request from downstream components.
+*** Config read when root port's link is down.
+
+* RCEIP +
+All the requirements for RCEIP in the PCIe Base specification shall be
+implemented.
+In addition the following requirements shall be met:
+** If RCEIP is implemented then RCEC shall be implemented as well. All
+requirements for RCEC specified in the PCIe Base specification shall be
+implemented. RCEC is required to terminate the AER and PME messages from RCEIP.
+** If both the topologies mentioned above are supported then RCEIP and RCEC
+shall be implemented in a separate PCIe domain and shall be addressable via a
+separate ECAM I/O region.
+
+====== PCIe peer to peer transactions +
+TBD

==== Secure Boot
* TEE
--
2.17.1


[PATCH 0/1] System peripherals - PCIe

Mayuresh Chitale
 

This is an initial patch for PCIe requirements for the server extension. The
goal is to specify requirements for those PCIe elements which interact with
the system such as PCIe config space, memory space, topology, interrupts etc.

Mayuresh Chitale (1):
server extension: PCIe requirements

riscv-platform-spec.adoc | 166 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 164 insertions(+), 2 deletions(-)

--
2.17.1


Re: UEFI/ACPI ECR process proposal

mark
 

do we have a glossary (with links if apropos)  for the acronyms in use in the docs (like IMSIC)? more than just what the acronym is for but like what the item is for and either a standards definition link or example links.

On Tue, Jun 29, 2021 at 8:36 AM Sunil V L <sunilvl@...> wrote:
Hi Team,

As we discussed in the Platform HSC meeting yesterday, I am attaching the snapshot of the slides presented. Please also go through the https://github.com/riscv/riscv-acpi/wiki/ACPI-ASWG-ECR-Process and get back with any feedback/questions.

Thanks

Sunil







UEFI/ACPI ECR process proposal

Sunil V L
 

Hi Team,

As we discussed in the Platform HSC meeting yesterday, I am attaching the snapshot of the slides presented. Please also go through the https://github.com/riscv/riscv-acpi/wiki/ACPI-ASWG-ECR-Process and get back with any feedback/questions.

Thanks

Sunil


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

Abner Chang
 



Jonathan Behrens <behrensj@...> 於 2021年6月29日 週二 上午2:32寫道:
What does "implementation specific" mean in this context? Could the platform spec require implementations to program the RTC with UTC times?
I don't think that is necessary to mention how to program the RTC in platform spec. We just need the RTC to keep counting the time. UEFI Time runtime service already provides the abstract API which the underlying algorithm to program RTC or incorporates with some other mechanisms is not defined.  The example I mentioned to incorporate with BMC is just one of the implementations.

If not, could it recommend/encourage them to?
  Yes, we still can provide some recommendations in the spec that encourages people to use RTC.
Abner
  

Jonathan

On Mon, Jun 28, 2021 at 11:31 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:


Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
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.
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

>
>
>     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: FW: [riscv/riscv-platform-specs] RVM platform requirements (#25)

Greg Favor
 

On Mon, Jun 28, 2021 at 2:03 PM Kumar Sankaran <ksankaran@...> wrote:

Is it realistic to require RV32G in order to comply with the RVM platform? It seems like a more natural choice would be RV32IMAF, as RV32D is pretty heavy on the floating-point for small microcontrollers (most Cortex-M devices don't even have double precision support in hardware, that's only available in the M55 and M7).


Keep in mind the distinction between RVM ISA profile specs and M platform specs.  I would expect that the M platform spec would require the RVM ISA profile spec.  But all the individual FP and C extensions are "Optional" in RVM20 and RVM22.  The M profile specs generally take the approach of setting a low "Required" bar and specify many extensions as supported but "Optional".

So the M 2022 platform spec can either simply accept that through its requirement for RVM22, or it can add on requirements for the F and C extensions (and possibly some other extensions).  Essentially the M platform spec can choose to require everything that constitutes RV32GC/RV64GC, or to stop a bit short (e.g. not requiring D), or stop way short.

I don't have a horse in this race, but I can imagine there being people on both sides of the argument as to whether the M platform spec should require more than what is required in the M profile spec, and if so how much more.

Greg


FW: [riscv/riscv-platform-specs] RVM platform requirements (#25)

Kumar Sankaran
 

Forwarding to tech mailing list.

 

Regards

Kumar

From: Torbjørn Viem Ness <notifications@...>
Sent: Monday, June 28, 2021 1:34 PM
To: riscv/riscv-platform-specs <riscv-platform-specs@...>
Cc: Subscribed <subscribed@...>
Subject: [riscv/riscv-platform-specs] RVM platform requirements (#25)

 

Great initiative!
I do however have questions about the requirements for the RVM platform, specifically the 32-bit version;

Is it realistic to require RV32G in order to comply with the RVM platform? It seems like a more natural choice would be RV32IMAF, as RV32D is pretty heavy on the floating-point for small microcontrollers (most Cortex-M devices don't even have double precision support in hardware, that's only available in the M55 and M7).

Also the C extension would make sense to include as embedded applications are quite sensitive to code size, but that's probably a different discussion worthy of its own issue...


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


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

Jonathan Behrens <behrensj@...>
 

What does "implementation specific" mean in this context? Could the platform spec require implementations to program the RTC with UTC times? If not, could it recommend/encourage them to?

Jonathan

On Mon, Jun 28, 2021 at 11:31 AM Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> wrote:


Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
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.
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

>
>
>     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: Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

Kumar Sankaran
 

https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

Yes, it includes all planned extensions.

 

Regards

Kumar

From: Mark Himelstein <markhimelstein@...>
Sent: Monday, June 28, 2021 11:04 AM
To: Kumar Sankaran <ksankaran@...>
Cc: tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

 

where are the current platform specifications that are under development being stored? does it include extensions?

 

Thanks

Mark

 

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

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: Next Platform HSC Meeting on Mon Jun 28 2021 8AM PST

mark
 

where are the current platform specifications that are under development being stored? does it include extensions?

Thanks
Mark

On Fri, Jun 25, 2021 at 1:36 PM Kumar Sankaran <ksankaran@...> wrote:
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/2] riscv-platform-spec: Real-time Clock to server extension

Abner Chang
 



Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道:
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.
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

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




721 - 740 of 1847