Public review for standard extension Smstateen

[Stephano Cetola]

We are delighted to announce the start of the public review period for
the following proposed standard extension to the RISC-V ISA:
Smstateen - State enable

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

This extension is part of the Privileged Specification.

This extension is described in the PDF spec available at:
https://drive.google.com/file/d/18z_TNyR8R7JLsxiAaF9hXwWPd_vQbOqP/view?usp=sharing

To respond to the public review, please email comments to the public
isa-dev mailing list. 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 Privileged ISA
Committee. 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

[Stephano Cetola]

Apologies on the mixup, the latest version of the spec is here:

https://drive.google.com/file/d/1M2o7OS0pEJAztA7OAg6ybrRjj0Yo-tCH/view?usp=sharing

I've updated the link to the specification on the combined list as well.

https://docs.google.com/document/d/1soGI__HytotOkoJtgTYD0nzf82Zhp5nWw1Mcgqvbn8o/edit

[Paul Donahue]

It is difficult to easily discern what is normative from what is non-normative in the Smstateen spec.

Although the covert channel argument alone justifies the extension, a less sinister situation justifying the extension is that guest operating systems may be naturally using an extension's state (rather than maliciously communicating).  Unless the hypervisor is context switching that state, it cannot allow the guests to use that state or the guests will overwrite each other.

This spec uses the terms "read-only zeros" and "read-only ones" which elsewhere in RISC-V is called "hardwired to zero" and "hardwired to one."

On page 8 "less-privilegeed level" contains a typo.

There is a paragraph that begins "For each mstateen and hstateen CSR, bit 63 is defined to control access to the matching supervisor-level sstateen CSR."  I think that it would be helpful to mention somewhere in that prose that mstateenX[63] also controls access to hstateenX (not just sstateenX).  That becomes clear later when all the bits are defined but I spoke to someone who thought that the sentence I quoted was intended to be a complete description of bit 63.

Thanks,

-Paul

[Allen Baum]

I thought the spec also used WARL-0  or WARL0 for read-only-0, but I can't see it anywhere It certainly labels fields as 0 (WARL)

--
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/1f6a0363-1e64-4593-b0c4-3072ae370237n%40groups.riscv.org.

[Paul Donahue]

The description of mstateen0 bit 59 ("Most other registers of the AIA") is very vague.  It is clarified later but it would be better to add "as explained later" or "see below" to have an explicit forward reference to the actual behavior.

In that same area it says "the following are also proposed initially for mstateen0."  That (and much of the document) reads like a proposal or even just a tentative idea.  That's inappropriate for a ratified specification (which this will presumably become).  The draft specification should include definitive language that can be either ratified as-is, modified, or rejected.

It might be the intent to just gather feedback on the concepts in the spec rather than the specific wording.  One thing I've learned is that what may seem like unimportant wording changes to one person can have substantial impacts on others who interpreted the previous wording differently.  Having the final normative text allows everyone to agree on what is actually being specified.

Thanks,

-Paul

On Friday, September 17, 2021 at 4:49:04 PM UTC-7 step...@riscv.org wrote:

[John Hauser]

Bit 60 of the stateen0 CSRs, which controls access to CSRs siselect

and vsiselect of the Advanced Interrupt Architecture (AIA), should also
control access to their partner CSRs sireg and vsireg.  Depending on
the value last assigned to siselect or vsiselect, information may be
improperly communicated through sireg and vsireg too.

    - John Hauser