Codify notion of M-mode profiles

[riscv]

Codify notion of M-mode profiles

[David-Horner]

Is it possible and desirable to define the essential features (minimal set, perhaps) that are required for an implementation to be standard compliant?

Do we need to make a distinction between hardware and software implementations to designate a domain specific compliance.

It is assumed that there can be full software implementations (emulations) on certain hardware that are fully compliant with both the U-mode and privilege specifications, and they would clearly be understood as such.

However, hardware implementations may not have the same transparency.

For example, if the CSRRxx instructions are all implemented by a dedicated CSRR instruction trap with the CSR registers maintained by a RV instruction sequences (and presumably some memory and hardware I/O), is that a compliant implementation?

[aswaterman]

Good question @David-Horner. IMO, the difference between HW and SW implementations is immaterial. I agree it's desirable to label something like qemu-linux-user a compliant RVU system, even though it doesn't implement the more-privileged modes at all. Likewise, I think that a HW implementation could have a completely non-compliant M-mode (or no M-mode?) and still implement RVS/RVU in a compliant fashion.

[David-Horner]

I gather the question is for the RISC-V foundation, if they are going to provide some kind of certification.

If the are, preparing some kind of relevant taxonomy differentiated by hardware/software, supported modes and measures of completeness in these domains would be appreciated, I think.

Do you think this is worthwhile?

[aswaterman]

Yes, though I'm not sure which Foundation working group will be responsible for this. For now it's probably a matter for the isa-dev mailing list.

IMO, the important distinction is which interfaces are provided, not how.

[David-Horner]

And yet practically it is how - the choice of CSR instructions vs memory mapped registers is because of the anticipated means of implementing.

ditto - for the trap/interrupt delegation process, that is explicit in CSR registers and not implicit as effects of various control or machine states that could otherwise be, for example, imposed externally, or hardwired for certain processor designs, or delegated to a more complex PLIC / CLIC. .
As with memory mapping the timer, the real world anticipated implementation mandated the change from CSR.

These interface are driven by implementation expectations and "universality" goals.

(Is there somewhere these expectations and goals can at least be consolidated and hopefully clarified. There are multiple trade-offs being considered, and perhaps an annotation with the relevant drivers, both in discussions and documents would be essential to comprehension and buy-in. This relates to the current topic, what are relevant M-mode profiles and how defined).

[kasanovic]

There is a compliance task group within the Foundation. At the first meeting at the last workshop, the consensus was that there was no need/ impossible to distinguish between hardware and software implementations of a feature. Hardware performance varies greatly with implementation technology and microarchitecture, and some features are best wholly or partly implemented in software. Instead, the proposal was that the compliance suite could include a set of microbenchmarks to measure the performance of each feature. This would allow users to downselect from available implementations based on their own performance profile needs.

[sorear]

The direction I'd like to go with this issue is roughly:

1. "RISC-V user ISA conformance is for an execution environment composed, in general, of both hardware and software. Hardware can support multiple execution environments, some of which are conformant with the RISC-V user ISA and some of which are not."
2. The priv spec defines a concept of "restricted environment"; which is a subset of the user spec where misaligned accesses, accesses to non-M-mode CSRs, FENCE, FENCE.I, and instructions outside of RVI(C) are not necessarily permitted. (This is conceptually similar to the LR/SC forward progress guarantees.)
3. "On reset, an environment which otherwise conforms to the M-mode privileged architecture MAY be executing in a restricted environment. It is the responsibility of the reset entry code to configure trap handlers to implement an unrestricted environment prior to transferring control to code which expects an unrestricted environment. Trap entry code MUST take appropriate measures to permit reentrancy prior to executing code which requires an unrestricted environment."

If you agree with the approach I can try to work that into a PR or discuss it in another forum.

[aswaterman]

I agree with those statements - not sure where they belong in the spec?

[aswaterman]

We've concluded this is a platform-architectural issue that, while important, is outside the scope of this document.