Public review for standard extension Smepmp (ePMP)

[Stephano Cetola]

We are delighted to announce the start of the public review period for
the following proposed standard extensions to the RISC-V ISA:
Smepmp - Enhance Physical Memory Protection (ePMP)

This extension is part of the Privileged Specification.

The review period begins today, Thursday Sept 16, and ends on Sunday
Oct 31 (inclusive).

These extensions are described in the PDF spec available at:
https://github.com/riscv/riscv-tee/blob/main/Smepmp/Smepmp.pdf

which was generated from the source available in the following GitHub repo:
https://github.com/riscv/riscv-tee/tree/main/Smepmp

To respond to the public review, please either email comments to the
public isa-dev mailing list or add issues and/or pull requests (PRs)
to the TEE GitHub repo: https://github.com/riscv/riscv-tee. We welcome
all input and appreciate your time and effort in helping us by
reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the TEE task group. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the Privileged ISA Committee will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Kind Regards,
Stephano
--
Stephano Cetola
Director of Technical Programs
RISC-V International

[Palmer Dabbelt]

I'm trying to sort out the state of things as per this thread on the Linux mailing list.  This one is listed as "Frozen and out for public review" on https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone , but the specification clearly says it's stable.  Which of those is accurate?

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEY315hT9DWxASjwaF_H6dssF3QowYOfcL3Y3Vj83tio0ksMrA%40mail.gmail.com.

[Greg Favor]

On Thu, Sep 30, 2021 at 9:31 AM Palmer Dabbelt <pal...@dabbelt.com> wrote:

I'm trying to sort out the state of things as per this thread on the Linux mailing list.  This one is listed as "Frozen and out for public review" on https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone , but the specification clearly says it's stable.  Which of those is accurate?

All specs out for public review (including this one) are officially Frozen.  For this and any other spec documents that weren't updated to state their new Frozen status, that is simply an oversight.  RVI, as we speak, is better communicating to TG's that all specs need to be accurately marked as to their official status (and what are the official states that a spec can be in).  Going forward this issue of uncertain or stale spec status should go away.

Greg

 

[Greg Favor]

On Thu, Sep 30, 2021 at 2:23 PM Nick Kossifidis <mi...@ics.forth.gr> wrote:

I was under the impression that the spec gets frozen after the public
review, since we may have changes/fixes during public review, that's why
I left it as stable.

There are a few states for an arch spec.  Later in its development it will reach a point deemed as Stable - which sets a certain bar to not changing things willy-nilly while the door is very much open to necessary changes to get to having a good quality arch extension.  Then there is the official Freeze milestone that on the one hand requires a lot of things to be accomplished before RVI approval is given to freeze the spec, and on the other hand is a necessary milestone before a spec can go to public review.  This state sets a much higher bar to change.  If public review uncovers a major flaw or problem that can only be addressed by a change in this spec, then that of course needs to be addressed.  But that should be a rare and very surprising situation.  The point is that the Task Group, and all of its participants, developing the spec should have done a "good" job - and it would behoove people that don't participate through the development process to at least check in when the spec becomes stable and raise questions and concerns before the spec goes to official Freeze status.  The spec will also go through an RVI Architecture Review process (by the ISA chairs), as well, before a spec can be frozen.

Lastly it's worth noting that this process over the past couple of years has been less clear and organized than what many would desire or expect, but for arch extensions going forward that is changing substantially for the better.

Greg

[Nick Kossifidis]

Thanks for the clarification, I thought that the process of officially
freezing the spec included the public review period, that we freeze the
spec internally after our own review by HCs/ICs and the TG, and
officially freeze the spec after receiving comments from the public
review, while we review them (so that no more comments can come in). The
definition of the freezing state
(https://wiki.riscv.org/display/HOME/Specification+States) used for
marking documents on github is not clear on this, it says "a change will
only occur because of some truly critical issue being identified during
the public review cycle" but it doesn't clarify if the public review
happens before or after marking something as officially frozen. Also the
page we use for tracking
(https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone)
is titled "extensions on deck for freeze milestone" and even extensions
like Smepmp that have "frozen & out for public review" checked are still
there (on deck for freeze milestone, as if they haven't reached the
freeze milestone / official freeze yet). Also the "Ratification Policy"
doc
(https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit)
includes the public review process under the "Freezing Milestone"
section, it even says "All public review comments must be resolved..."
and "Public review comments and responses will be stored in the top
sheet." (the top sheet for the freezing milestone) so one may think that
even resolving the public review comments is also part of reaching the
freezing milestone. The only document I found where it's clear that
public review happens after we reach the freezing milestone is the
"extension lifecycle and milestone definitions"
(https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.ga0a994c3c8_0_6)
which is inconsistent with "Ratification Policy" since it includes the
public review and the resolution of public review comments as part of
the vote-ready milestone.

I updated the doc on github to be consistent with "extension lifecycle
and milestone definitions", marking the spec as frozen.

Regards,
Nick

[Greg Favor]

Nick,

Thanks.  This is all good feedback to us and the RISC-V program managers (Stephano and Jeff).  The recent push to get a lot of new arch extensions frozen and out to public review was the first time wrt all the policies that are being put in place, and so it isn't surprising that there are a number of rough edges that need to be cleaned up and handled better as we all go forward.

Greg

[Palmer Dabbelt]

Nick's issues are broadly the same as what I was pointing out on the LKML thread where we're trying to figure out what frozen actually means (and I guess also what versions also mean).  IIUC that "Frozen &" clause was added very recently as a result of my confusion with the "On-Deck for Frozen Milestone" table not being an obvious name for the list of currently frozen specifications, but it sounds like some other folks are confused as well.

Generally the software folks have been putting a lot of weight behind an specification being marked as frozen, as that's the point at which we have been considering it part of the canonical set of RISC-V specifications with which compatibility will be maintained forever.  I'm not really plugged into the foundation stuff these days, but it's really scary to see that the first author of a specification is also confused about whether or not that specification is frozen.  It certainly seems like there's a lot of misalignment within the foundation about how specifications should be marked as frozen and what exactly is being frozen.  We've already got enough confusion about these sorts of things, and I don't want to end up in that sort of spot again with this round.

Are you guys planning on producing some sort of internally-consistent description of this frozen milestone (ie: what's being frozen, how things get there, and what can change afterwards) and checking to make sure the authors are on board with that, or do I need to go around and check with the various specification authors myself to make sure they're on board with supporting the software ecosystem before we start taking code that depends on that support?

[Greg Favor]

On Thu, Sep 30, 2021 at 7:42 PM Palmer Dabbelt <pal...@dabbelt.com> wrote:

Generally the software folks have been putting a lot of weight behind an specification being marked as frozen, as that's the point at which we have been considering it part of the canonical set of RISC-V specifications with which compatibility will be maintained forever. 

That is the intent of the Freeze status for a spec.

 

I'm not really plugged into the foundation stuff these days, but it's really scary to see that the first author of a specification is also confused about whether or not that specification is frozen.  It certainly seems like there's a lot of misalignment within the foundation about how specifications should be marked as frozen and what exactly is being frozen.  We've already got enough confusion about these sorts of things, and I don't want to end up in that sort of spot again with this round.

Understood.  This is all happening in "real time" over the past month, so inconsistencies and confusions aren't surprising but certainly need to be addressed for all new arch extension work going forward - which is exactly the intention of RVI now that we have gotten this backlog of extensions into public review.

 

Are you guys planning on producing some sort of internally-consistent description of this frozen milestone (ie: what's being frozen, how things get there, and what can change afterwards) and checking to make sure the authors are on board with that,

Yes.  This is being documented and starting to be communicated.  (And I say "starting" simply because a single communication in, for example, the Tech Chairs weekly meeting that all TG chairs should be attending will invariably not be sufficient.  Which is fine.  This just needs to be communicated a few times.)

 

or do I need to go around and check with the various specification authors myself to make sure they're on board with supporting the software ecosystem before we start taking code that depends on that support?

No.  And all the gates to allowing a spec to be officially declared as Frozen, serve to ensure that a spec is worthy of being Frozen and a basis for the software ecosystem to upstream support.

Greg