[BUG] no Spike configuration to disable S-mode [compliance, csr and tests-p failing on master]

[cathales]

Is there an existing CVA6 bug for this?

• [X] I have searched the existing bug issues

Bug Description

master branch has 3 failing tests since 4b67475fa452e9d363a22f9c47280fe54c4e780b:

• compliance (regress)
• tests-p (regress)
• csr (verif)

These three jobs pass on the direct parent commit 53d388071d51f4cca018e5f4ddf08ccacb45ecff

So https://github.com/openhwgroup/cva6/pull/1574 revealed issues with these tests, and the CI is red since.

[ASintzoff]

@AEzzejjari could you take a look at this issue (related to condition on S-mode)?

[AEzzejjari]

This bug is caused by Spike, which supports supervisor mode unlike the embedded version of cva6. Therefore, we need to modify Spike's configuration to disable SMODE and trigger an exception when accessing a supervisor mode register, as cva6 did.

[zarubaf]

I think you need to disable S mode in spike. If you ./configure you can run:

  --with-isa=RV64IMAFDC_zicntr_zihpm
                          Sets the default RISC-V ISA
  --with-priv=MSU         Sets the default RISC-V privilege modes supported

Maybe --with-priv=M could do it?

[ASintzoff]

I would suggest to use the option --priv=<m|mu|msu> RISC-V privilege modes supported [default MSU] when executing spike. This will avoid building multiple spike executables.

[MarioOpenHWGroup]

There is a bug in current spike implementation that does not let to change priv with the param, I am working on fixing it.

[zchamski]

There's another potential issue with Spike: at first analysis, the Spike model instantiates all CSRs from the RISC-V specs no matter what restrictions are imposed on the current privilege set. This means that there is no way to "remove" (mark as "inexistent") the CSRs of a temporarily unsupported privilege level. E.g., with the privilege set restricted to Machine only (--priv=M), the sstatus CSR will still be present and usable from machine mode.

[zchamski]

Chapter 3 of The Privileged Spec V20211203 says:

The RISC-V machine-level ISA contains a common core that is extended depending on which other privilege levels are supported and other details of the hardware implementation.

The next paragraph (start of Section 3.1) states that;

In addition to the machine-level CSRs described in this section, M-mode code can access all CSRs at lower privilege levels.

According to the first quoted text, if no privilege levels lower than M-mode are supported and the hardware implementation decides so, the CSRs at lower privilege levels can be omitted (and treated as non-existent).

[MarioOpenHWGroup]

Already solved