Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Guo Ren

The current Privileged specification only defines Svnapot and Svpbmt for RV64 with the highest bits in PTE, and there are no spare highest bits in rv32 for 34-bit physical addressing. But "the lack of rv32 in svpbmt was a very odd choice [1]" mentioned by Christoph Hellwig (Linux DMA MAPPING HELPERS Maintainer), that's very true in practice requirements, and it also blocks the development of rv32-Linux cost-down chip production.

Rv32-Linux currently only supports 1GB of DRAM for maximum, and there is no plan for high-memory. So, there seems to be no obstacle to shrinking the physical address space of the rv32 from 16GB to 2GB. Then we have enough highest bits to hold Svnapot & Svpbmt.

We've finished the Linux Proof of concept of the proposal, which contains
three parts:
- Qemu rv32 svpbmt & napot support & hw/virt memory layout of 1GB IO
range [2]
- rv32-Linux kernel Svnapot & Svpbmt support [3]
- Opensbi needs to compile with FW_TEXT_START=0x40000000

[1] https://lore.kernel.org/linux-riscv/YsRzVoWOdGqSOZ+q@.../
[2] https://github.com/guoren83/qemu/tree/rv32svpbmt
[3] https://lore.kernel.org/linux-riscv/20220710075644.738455-1-guoren@.../

The draft spec below provides all the details. Note that this extension very specifically strives to maintain maximal consistency with many little details in the existing Privileged architecture.

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.

Thanks,
Guo Ren

========================================================================

\section{Sv32: Page-Based 32-bit Virtual-Memory Systems}
\label{sec:sv32}
...
\subsection{Svnapot and Svpbmt}
\label{sec:translation}

Sv32 implementations could support Svnapot (Chapter~\ref{svnapot}) and Svpbmt (Chapter~\ref{svpbmt}) with reduced physical address space from 34-bit to 31-bit when {\tt menvcfg}.PBMTE is set. Then the leaved highest three bits are used to support Svnapot and Svpbmt. The 20-bit VPN is translated into a 19-bit physical page number (PPN).

\begin{commentary}
For example, consider an RV32 system supporting 31 bits of physical address with Svnapot and Svpbmt. When the value of {\tt satp}.MODE is Sv32 and {\tt menvcfg}.PBMTE is set, and a 31-bit physical address is produced directly.
\end{commentary}

| 31  22 | 21  12 | 11        0 |
VPN[1]   VPN[0]   page offset    10       10         12

| 30  22 | 21  12 | 11        0 |
PPN[1]   PPN[0]   page offset    9        10         12
Sv32 page table entry with Svnapot and Svpbmt:
| 31 | 30 29 | 28     10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
N    MT[2]   RSV & PFN   reserved for SW   D   A   G   U   X   W   R   V
========================================================================

=======================  Supervisor Extension Mix modification  ===================

diff --git a/src/supervisor.tex b/src/supervisor.tex@@ -2271,7 +2370,7 @@ equals 8.
\chapter{Svnapot'' Standard Extension for NAPOT Translation Contiguity, Version 1.0}
\label{svnapot}

-In Sv39, Sv48, and Sv57, when a PTE has N=1, the PTE represents a
+In Sv32, Sv39, Sv48, and Sv57, when a PTE has N=1, the PTE represents a
translation that is part of a range of contiguous virtual-to-physical
translations with the same values for PTE bits 5--0.  Such ranges must be of a
naturally aligned power-of-2 (NAPOT) granularity larger than the base page
@@ -2364,7 +2463,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
Depending on need, the NAPOT scheme may be extended to other intermediate
page sizes and/or to other levels of the page table in the future.  The
encoding is designed to accommodate other NAPOT sizes should that need
-  arise.  For example:
+  arise.  For example in Sv39:

\begin{center}\em
\begin{tabular}{|c|c||l|c|}
@@ -2384,6 +2483,23 @@ algorithm in Section~\ref{sv32algorithm}, except that:
\end{tabular}
\end{center}

+  For example in Sv32:
+
+  \begin{center}\em
+  \begin{tabular}{|c|c||l|c|}
+  \hline
+  i        & $pte.ppn[i]$      & Description                & $pte.napot\_bits$ \\
+  \hline
+  0        & {\tt x~xxxx~xxx1} & 8 KiB contiguous region    & 1 \\
+  0        & {\tt x~xxxx~xx10} & 16 KiB contiguous region   & 2 \\
+  ...      & ...               & ...                        & ... \\
+  1        & {\tt x~xxxx~xxx1} & 8 MiB contiguous region    & 1 \\
+  1        & {\tt x~xxxx~xx10} & 16 MiB contiguous region    & 2 \\
+  ...      & ...               & ...                        & ... \\
+  \hline
+  \end{tabular}
+  \end{center}
+
In such a case, an implementation may or may not support all options.  The
discoverability mechanism for this extension would be extended to allow
system software to determine which sizes are supported.
@@ -2399,7 +2515,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
\chapter{Svpbmt'' Standard Extension for Page-Based Memory Types, Version 1.0}
\label{svpbmt}

-In Sv39, Sv48, and Sv57, bits 62--61 of a leaf page table entry indicate the use
+In Sv32, bits 31--29 or in Sv39, Sv48, and Sv57 of a leaf page table entry indicate the use
of page-based memory types that override the PMA(s) for the associated memory
pages.  The encoding for the PBMT bits is captured in Table~\ref{pbmt}.

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin

On Mon, Jul 11, 2022 at 7:54 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

My point is that the information, regardless of format, needs to be conveyed in some manner to the OS. There's no getting around that aspect. We need to identify 1. all the things the OS needs and 2. how to convey that information for consumption. We're currently talking about #1 and whether a name or whatever is applied to a construct that construct still needs to be properly conveyed. The Profile proposal in its current form is providing names to some of those constructs. Whether that continues and we embrace it going forward is now up for discussion it seems, but that discussion doesn't negate the fact that we have to enumerate many things to the OS for it to make correct decisions.

Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

I don't think the having a name for something or not reduces comprehensibility of discovery info. It all needs to be enumerated in one form or another. The question is how to get to a consistent way to describing these constructs across the ecosystem. The divide and conquer approach will work, but I'm not sure we'll get consistent names. If that's not a goal, so be it. Either way, we need to go and backfill things that don't have names/identifiers.

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

In order to focus on the discovery methods we need to have the set of things needed by each level the software to be enumerated and provide a way to name/identify those pieces. As you noted above, there may be different types needed, but that requirement falls out from the data gatherig step. However, we'll still need to figure out how to encode all this information anyway for DT and ACPI.

Greg

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor

On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

Greg

Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor

On Mon, Jul 11, 2022 at 2:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking.
Given that this does not provide a significant benefit, it seems safer to stick with the canonical form listing the base and individual extensions.

What is the expected benefit from duplicating this information?

This was a point I tried to make in another thread about tech-config and profiles.  Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified the support for further extensions).

So the question - that should be answered by the direct software user community of tech-config discovery structures - is whether the rest of a tech-config structure must only specify supported extensions not mandated by a profile, or must it also specify (redundantly) all the supported individual extensions, or is any degree of redundancy from zero to full allowed?

For example, having full redundancy would allow someone to simply check for presence of a specific extension of interest - without having to also check profile presence bits and understand what each of them implies.  Conversely, does someone feel that any redundancy creates confusion or complications for software using tech-config structures?

The rest of us can raise questions, but the direct users of tech-config are the best ones to determine the right answer.

Greg

Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Philipp Tomsich <philipp.tomsich@...>

Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking.
Given that this does not provide a significant benefit, it seems safer to stick with the canonical form listing the base and individual extensions.

What is the expected benefit from duplicating this information?

Philipp.

On Mon, 11 Jul 2022 at 23:15, Allen Baum <allen.baum@...> wrote:
Greg and I did discuss having Unified Discovery (UD) description macros for profiles, e.g. an RV22A bit that indicates support for all of the individual extensions (and option value ranges) required to meet the profile requirements.
This was in addition to, not replacement of, all the individual requirements, so you'd still have to set the values for each individual required extension.

The idea of have a macro "bit" (perhaps) for a union of different features, and a way to  carve out/remove (and probably replace) some specific extension or option is an interesting one, but sounds fraught with possible weird corner cases.

On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:

On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022 at 11:02 AM Aaron Durbin <adurbin@...> wrote:
On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.
Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.

Somewhat related, will we have a common way to refer to a Profile that identifies itself as a Profile that can be conveyed as a whole to an OS? This discussion is very much analogous to the toolchain discussion which leads to implementations that may not entirely implement a Profile may want set operations for carve outs for non-conformance. But either way, the SW that is being provided this information has to have a way to identify and keep track of these concepts anyway because it needs to deal both with Profiles proper and the exploded components regardless.

If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.

Practically speaking they should have a reasonably self-descriptive (yet short-ish) name.  Maybe simply "mandate names"?  This also avoids any confusion with extension names and with K and V names that would be used in discovery structures.  This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).

Greg

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum

Greg and I did discuss having Unified Discovery (UD) description macros for profiles, e.g. an RV22A bit that indicates support for all of the individual extensions (and option value ranges) required to meet the profile requirements.
This was in addition to, not replacement of, all the individual requirements, so you'd still have to set the values for each individual required extension.

The idea of have a macro "bit" (perhaps) for a union of different features, and a way to  carve out/remove (and probably replace) some specific extension or option is an interesting one, but sounds fraught with possible weird corner cases.

On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:

On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022 at 11:02 AM Aaron Durbin <adurbin@...> wrote:
On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.
Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.

Somewhat related, will we have a common way to refer to a Profile that identifies itself as a Profile that can be conveyed as a whole to an OS? This discussion is very much analogous to the toolchain discussion which leads to implementations that may not entirely implement a Profile may want set operations for carve outs for non-conformance. But either way, the SW that is being provided this information has to have a way to identify and keep track of these concepts anyway because it needs to deal both with Profiles proper and the exploded components regardless.

If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.

Practically speaking they should have a reasonably self-descriptive (yet short-ish) name.  Maybe simply "mandate names"?  This also avoids any confusion with extension names and with K and V names that would be used in discovery structures.  This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).

Greg

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin

On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022 at 11:02 AM Aaron Durbin <adurbin@...> wrote:
On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.
Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.

Somewhat related, will we have a common way to refer to a Profile that identifies itself as a Profile that can be conveyed as a whole to an OS? This discussion is very much analogous to the toolchain discussion which leads to implementations that may not entirely implement a Profile may want set operations for carve outs for non-conformance. But either way, the SW that is being provided this information has to have a way to identify and keep track of these concepts anyway because it needs to deal both with Profiles proper and the exploded components regardless.

If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.

Practically speaking they should have a reasonably self-descriptive (yet short-ish) name.  Maybe simply "mandate names"?  This also avoids any confusion with extension names and with K and V names that would be used in discovery structures.  This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).

Greg

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor

On Mon, Jul 11, 2022 at 11:02 AM Aaron Durbin <adurbin@...> wrote:
On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.
Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.

Practically speaking they should have a reasonably self-descriptive (yet short-ish) name.  Maybe simply "mandate names"?  This also avoids any confusion with extension names and with K and V names that would be used in discovery structures.  This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).

Greg

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin

On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

The combinatorics of taking every optional behavior, every parameter that can take on a set of possible values, and every WARL field and the allowed range of possibilities, and then creating an "extension" name for every individual possible "key- value" pair are crazy.  (This is why people instead use key-value representations.)

For Profiles, these names have been created on an as-needed basis for specific "key-value" pairs, and no further.  Their motivation was to simply have acronymic "extension" names for each of these line items.

In contrast, discovery schemes - like Device Tree, ACPI, and RISC-V Unified Discovery - want something distinctly different.  Namely standard "key" names for options, parameters, and WARL fields; standard names for the values of a "key"; and a schema for representing a set of key-value pairs.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.

Lastly, I think everyone would agree that option / parameter / WARL field names, and their associated value names, are not "extensions".  And hence should not be mixed up with the "extension" names created and used in Profiles.  Any standardization of "key" names and "value" names should simply focus on usage in discovery schemes (i.e. DT, ACPI, UD).  This needs to support all possible key-value pairs.

As to whether all these acronymic line items or "key-value" pairs in Profiles are "extensions", there is probably contention, but I would at least say that these are not extensions in the usual sense.  And they should exist and arise solely in the context of Profiles (for the intended purpose of giving an extension-like acronymic name to each line item).

If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

In short, I would suggest that it is probably best to keep discussion of these two topics separate.

Greg

On Fri, Jul 8, 2022, 1:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum

Unfortunately, I don't a have single term that would adequately convey the idea.
Greg and I were batting around some invented words
(e.g. "poption" as a portmanteau of profile-option was my first attempt. It did get better, but that's a low bar)
but nothing that you'd find in any dictionary.

On Mon, Jul 11, 2022 at 6:48 AM Aaron Durbin <adurbin@...> wrote:

On Fri, Jul 8, 2022 at 2:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions' and 'options' within the current proposal for these newly coined names.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin

On Fri, Jul 8, 2022 at 2:38 PM Allen Baum <allen.baum@...> wrote:
I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).
Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?
I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth,
as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.
The intent of this is to be able to configure the Sail model to implement the behavior they control.

Identifier in the sense of a short name/phrase that refers to these ideas. Consumers of that would be both software and day-to-day discussion as it's a succinct identifier that refers to an idea in prose.

Take the Zic64b "extension": it's a shortcut for "Cache blocks must be 64 bytes in size, naturally aligned in the address space." However, there are 3 different cache block operations. So while a Profile name could refer to the whole set of bold options/extensions, there are cases where a system doesn't adhere to a Profile. So how does one convey the cache block size (even if it's 32 bytes for all 3 cache block operations)? I think having a way to identify those architectural options can be very powerful.

FWIW, I completely thought of the the architectural test work you are doing, but I failed to directly mention it in my original email, Allen. Sorry about that.

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin

On Fri, Jul 8, 2022 at 2:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions' and 'options' within the current proposal for these newly coined names.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor

To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

The combinatorics of taking every optional behavior, every parameter that can take on a set of possible values, and every WARL field and the allowed range of possibilities, and then creating an "extension" name for every individual possible "key- value" pair are crazy.  (This is why people instead use key-value representations.)

For Profiles, these names have been created on an as-needed basis for specific "key-value" pairs, and no further.  Their motivation was to simply have acronymic "extension" names for each of these line items.

In contrast, discovery schemes - like Device Tree, ACPI, and RISC-V Unified Discovery - want something distinctly different.  Namely standard "key" names for options, parameters, and WARL fields; standard names for the values of a "key"; and a schema for representing a set of key-value pairs.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

Lastly, I think everyone would agree that option / parameter / WARL field names, and their associated value names, are not "extensions".  And hence should not be mixed up with the "extension" names created and used in Profiles.  Any standardization of "key" names and "value" names should simply focus on usage in discovery schemes (i.e. DT, ACPI, UD).  This needs to support all possible key-value pairs.

As to whether all these acronymic line items or "key-value" pairs in Profiles are "extensions", there is probably contention, but I would at least say that these are not extensions in the usual sense.  And they should exist and arise solely in the context of Profiles (for the intended purpose of giving an extension-like acronymic name to each line item).

In short, I would suggest that it is probably best to keep discussion of these two topics separate.

Greg

On Fri, Jul 8, 2022, 1:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).
Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?
I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth,
as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.
The intent of this is to be able to configure the Sail model to implement the behavior they control.

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
(which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented).
So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Direction of Identifying Extensions

Aaron Durbin

Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

Re: Proof of concept for rv32 svpbmt support

Guo Ren

On Wed, Jul 6, 2022 at 1:52 PM Greg Favor <gfavor@...> wrote:

I suspect someone could pursue standardization of this via the fast-track extension process.
Okay, I would try the fast-track extension process.

Greg

On Tue, Jul 5, 2022 at 4:55 PM Guo Ren <guoren@...> wrote:

Make rv32 support svpbmt & napot by reducing the PPN witdth (sv32p34 ->
sv32p31).

RISC-V 32bit also requires svpbmt in cost-down chip embedded scenarios,
and their RAM is limited (No more than 1GB). It is worth mentioning that
rv32-Linux currently only supports 1GB of DRAM, and there is no plan for
high-memory. So, there seems to be no obstacle to shrinking the physical
address space of the rv32 from 16GB to 2GB. We recommend that ISA
consider sv32p31 as the recommended configuration for the software
ecosystem instead of sv32p34. Then we could merge rv64 & rv32 into one
PTE format:

| XLEN-1 | XLEN-2 XLEN-3 | XLEN-4 10 | 9 8 | 7 | 6 | 5 | 4
| 3 | 2 | 1 | 0
N MT[2] RSV & PFN reserved for SW D A G U
X W R V

We've finished the Linux Proof of concept of the proposal, which contains
three parts:
- Qemu rv32 svpbmt & napot support & hw/virt memory layout of 1GB IO
range [1]
- Linux rv32 sv32p31 & svpbmt support [2]
- Opensbi needs to compile with FW_TEXT_START=0x40000000

[1] https://github.com/guoren83/qemu/tree/rv32svpbmt
[2] https://lore.kernel.org/linux-riscv/20220705100523.1204595-1-guoren@kernel.org/T/#mf1d7089d45d9a2501ca71f4986235241985bfc19

--
Best Regards
Guo Ren

Re: Proof of concept for rv32 svpbmt support

Greg Favor

I suspect someone could pursue standardization of this via the fast-track extension process.

Greg

On Tue, Jul 5, 2022 at 4:55 PM Guo Ren <guoren@...> wrote:
Make rv32 support svpbmt & napot by reducing the PPN witdth (sv32p34 ->
sv32p31).

RISC-V 32bit also requires svpbmt in cost-down chip embedded scenarios,
and their RAM is limited (No more than 1GB). It is worth mentioning that
rv32-Linux currently only supports 1GB of DRAM, and there is no plan for
high-memory. So, there seems to be no obstacle to shrinking the physical
address space of the rv32 from 16GB to 2GB. We recommend that ISA
consider sv32p31 as the recommended configuration for the software
ecosystem instead of sv32p34. Then we could merge rv64 & rv32 into one
PTE format:

| XLEN-1 | XLEN-2 XLEN-3 | XLEN-4 10 | 9             8 | 7 | 6 | 5 | 4
| 3 | 2 | 1 | 0
N        MT[2]           RSV & PFN   reserved for SW   D   A   G   U
X   W   R   V

We've finished the Linux Proof of concept of the proposal, which contains
three parts:
- Qemu rv32 svpbmt & napot support & hw/virt memory layout of 1GB IO
range [1]
- Linux rv32 sv32p31 & svpbmt support [2]
- Opensbi needs to compile with FW_TEXT_START=0x40000000

[1] https://github.com/guoren83/qemu/tree/rv32svpbmt
[2] https://lore.kernel.org/linux-riscv/20220705100523.1204595-1-guoren@.../T/#mf1d7089d45d9a2501ca71f4986235241985bfc19

Proof of concept for rv32 svpbmt support

Guo Ren

Make rv32 support svpbmt & napot by reducing the PPN witdth (sv32p34 ->
sv32p31).

RISC-V 32bit also requires svpbmt in cost-down chip embedded scenarios,
and their RAM is limited (No more than 1GB). It is worth mentioning that
rv32-Linux currently only supports 1GB of DRAM, and there is no plan for
high-memory. So, there seems to be no obstacle to shrinking the physical
address space of the rv32 from 16GB to 2GB. We recommend that ISA
consider sv32p31 as the recommended configuration for the software
ecosystem instead of sv32p34. Then we could merge rv64 & rv32 into one
PTE format:

| XLEN-1 | XLEN-2 XLEN-3 | XLEN-4 10 | 9             8 | 7 | 6 | 5 | 4
| 3 | 2 | 1 | 0
N        MT[2]           RSV & PFN   reserved for SW   D   A   G   U
X   W   R   V

We've finished the Linux Proof of concept of the proposal, which contains
three parts:
- Qemu rv32 svpbmt & napot support & hw/virt memory layout of 1GB IO
range [1]
- Linux rv32 sv32p31 & svpbmt support [2]
- Opensbi needs to compile with FW_TEXT_START=0x40000000

[1] https://github.com/guoren83/qemu/tree/rv32svpbmt
[2] https://lore.kernel.org/linux-riscv/20220705100523.1204595-1-guoren@.../T/#mf1d7089d45d9a2501ca71f4986235241985bfc19

Call for Chair/Vice-Chair Candidates for Performance Analysis SIG

Beeman Strong

This is a call for chair and vice-chair candidates for the recently created Performance Analysis SIG (umbrella: Privileged Software HC)

All candidates must submit a biography (bio) and statements of intent by July 8th 2022. The policy describing this process is here.

The current draft charter of the Perf Analysis SIG can be found here.

Nomination process, requirements, and duties:

If you would like to be included or know someone who should be, please send an email to help@... with the candidate's name, member affiliation, qualifications, a small bio and a statement of intent (both less than 250 words each).

Qualifications include:
- Experience with CPU and/or SoC performance monitoring (PMU) architecture
- Experience with software performance analysis methodologies, tools, and libraries
- Experience with systems software (OS, hypervisors, drivers) and PMU enabling
- Basic familiarity with CPU and/or SoC microarchitecture

Duties as chair/vice-chair (see Best Practices document) include:

- Collaboration with existing task groups within the RISC-V Foundation
- Seek contributions/collaborations while keeping focus on SIG charter
- Publish meeting minutes
- Community interactions through meetings, mail list, GitHub, Wiki
- Respond to queries within 48 hours
- Manage and run regular meetings as per the group charter
- Attend weekly tech-chairs meetings

Thanks,
Beeman Strong
Acting Chair

 161 - 180 of 1210