[DISCUSS] Unpriv tests cannot write to CSR

[MikeOpenHWGroup]

This discussion is a continuation of #1116 that has been closed (appropriately), but some discussion from that Issue is still on-ging (here).

We can't write to that CSR during the test because it is an unpriv test so we don't use any priv features (like M-mode CSRs).

That is not how we should read the specs. If a core supports M-mode CSRs, it must be possible for a test-program to write them. Simple microcontrollers, particularly those implemented before the RVI20 Profile was defined, will always operate in M-mode and thus be able to write/read CSRs via the csr* instructions.

[davidharrishmc]

The RV32I_Zicntr processor built by students in my undergraduate class does not have any privilege modes or M-mode CSRs. That appears to be compliant with at least the unpriv spec, and I don't see that the priv spec is required.

[MikeOpenHWGroup]

OK, now I'm confused. How to you access cycle, time, and instret without CSR instructions? How do you get CSR instructions without Zicsr?

[davidharrishmc]

Zicntr depends on Zicsr, which implies implementing the unprivileged CSR* instructions (see unprivileged manual chapter 6).
Zicsr does not require the existence of M-mode.

While CSRs are primarily used by the privileged architecture, there are several uses in
unprivileged code including for counters and timers, and for floating-point status.

The Zicntr extension depends on the Zicsr extension.

[davidharrishmc]

This made me dizzy for weeks, but I think I fully understand it now.

[MikeOpenHWGroup]

Indeed. So, if I were to change my original comment to say "If a core supports CSRs, it must be possible for a test-program to write them" it seems we are aligned.

So why can't the ACTs write to mountinhibit.IR and mcountinhibit.CY? @jordancarlin's objection was that unpriv tests should not write CSRs. That should be fine because we won't be reading them either, so the fact that the cycle and instret counters may or may not be counting is irrelevant to the unpriv tests. It seems even for an RV32I_Zicntr processor (which appears to be a valid implementation of the RVI20 Profile) that some priv testing will be required.

[jordancarlin]

I should clarify my statement to say that unpriv tests should not read or write privileged CSRs. They can (and do) read/write unprivileged CSRs like counters and fcsr.

[allenjbaum]

Jordan is, of course, entirely correct. Unpriv tests should not require access to priv (specifically Mmode) CSRs. However, unpriv tests may require that Mmode CSR state is initialized such that the test will properly run. That should (IMHO) be a requirement for the support required in RVMODEL_BOOT code, and specifically how an unpriv test can perform that initialization (because different tests will require different initialization, and often require changing that configuration inside a nominally unpriv test. The architecture provides the mechanism (as seen from an unpriv test) with SBI calls, which in turn (are intended to) use the unpriv ECALL ops. All Mmode implementations must support that (it is an unpriv op that all implementations must support, though it isn't defined what exactly it does unless delegated to a non-Mmode handler. Tests will need to use that mechanism if the DUT doesn't support the ratified Mmode.

…

On Wed, Mar 25, 2026 at 8:33 AM Jordan Carlin ***@***.***> wrote: I should clarify my statement to say that unpriv tests should not read or write *privileged* CSRs. They can (and do) read/write *unprivileged* CSRs like counters and fcsr. — Reply to this email directly, view it on GitHub <#1130?email_source=notifications&email_token=AHPXVJQFLPESBBNF52DPSKT4SP34TA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGEYTIOJZUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16311499>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWQGVELSE733YURWO34SP34TAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZRGE2DSOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[davidharrishmc]

Mike, one of us is misunderstanding the other.

RV32I_Zicsr_Zicntr is a legal configuration with no privilege modes. RV32I_Sm_Zicsr_Zicntr is also a legal configuration and has machine mode.

The Zicntr test suite is an unprivileged test that does things such as check if instret increments. It should run on RVI32I_Zicsr_Zicntr and also on RV32I_Sm_Zicsr_Zicntr.

On RVI32I_Zicsr_Zicntr, mcountinhibit is reserved, so writing it has an UNDEFINED behavior that could include Halt and Catch Fire. Therefore, the Zicntr suite cannot write mcountinhibit. Even if a nonstandard M-mode is defined, there is still no guarantee that mcountinhibit is safe to write.

On the other hand, you've discovered that in RV32I_Sm_Zicsr_Zicntr, mcountinhibit could reset to the wrong value and break the instret test.

The best solution I see is for the DUT to have some boot code to initialize mcountinhibit if necessary and appropriate to that DUT.

There could be an SBI call in the Zicntr test to write mcountinhibit, and the SBI call could be implemented as nop if there is no M-mode, but that seems like overkill.

In the more general case, I agree with Allen that the RVMODEL_BOOT requirements need to be fully defined, and can use whatever features the DUT has to put the system into a mode capable of running the applicable tests.

[MikeOpenHWGroup]

Thanks for the clarification @jordancarlin and @allenjbaum. For our embedded class cores, I'd like to avoid the SBI if at all possible. Is it satisfactory to place initialization of mcountinhibit in the RVMODEL_BOOT macro with a simple CSR write instruction (that is, csrwi mcountinhibit, 0)?

Assuming that is OK, this leaves the question of what is the full scope of such initializations and where should they be captured? We
discovered the mcountihibit issue because the CV32E40P implementation selected a power-on-reset that was not envisioned, so it seems a manual review will be required.

I'm envisioning a new chapter in the CRD that lists the required CSR initialization. We could, if desired, define a new macro to be executed immediately following RVMODEL_BOOT, or specify that the init code should be placed in BOOT.

In an effort to provide an illustrative example, here is a list of power-on-reset values and r/w masks for the CV32E40P: CV32E40Pv1_CSR_Cheat_Sheet - Machine-Mode CSR Cheat Sheet.pdf. The spreadsheet should probably have another column to identify which of these CSRs fall under the jurisdiction of RVI20 ACTs.

[MikeOpenHWGroup]

Mike, one of us is misunderstanding the other.

You're being generous David - it is I who misunderstood you.

RV32I_Zicsr_Zicntr is a legal configuration with no privilege modes. RV32I_Sm_Zicsr_Zicntr is also a legal configuration and has machine mode. The Zicntr test suite is an unprivileged test that does things such as check if instret increments. It should run on RVI32I_Zicsr_Zicntr and also on RV32I_Sm_Zicsr_Zicntr.

OK, but the CV32E40P is an odd-ball core that implements more CSRs than specified for RV32IMC_Zicsr_Zicntr, but (probably) not all CSRs specified for RV32IMC_Sm_Zicsr_Zicntr. We can still obtain an RVI20 certification for RV32IMC_Zicsr_Zicntr, but we'll need to initialize mcountinhibit in the RVMODEL_BOOT (or similar) macro.

On the other hand, you've discovered that in RV32I_Sm_Zicsr_Zicntr, mcountinhibit could reset to the wrong value and break the instret test.

Indeed. That motivated the generation of the previously attached spreadsheet.

[allenjbaum]

While we could require RVMODEL_BOOT to do this, I'm uncomfortable having everyone's RVMODEL_BOOT include initialization that a test (or implementation) doesn't need. I'd rather have the test initialize explicitly, using the SBI approach. Note that isn't the full ratified SBI spec, just the minimum to allow a test to initialize an Mmode CSR, and not much else. That support should be pretty cheap (I'm documenting it) basically ILLEGAL_OP handler that checks if it's an Mmode CSR op, writes it into the handler (self modifying code), fence.i, executes it, and returns. That's about a dozen lines of code exclusive of the trap prolog and epilog. Now, if you don't expect to ever see other illegal ops, its half that.

…

On Wed, Mar 25, 2026 at 12:00 PM Mike Thompson ***@***.***> wrote: Mike, one of us is misunderstanding the other. You're being generous David - it is I who misunderstood you. RV32I_Zicsr_Zicntr is a legal configuration with no privilege modes. RV32I_Sm_Zicsr_Zicntr is also a legal configuration and has machine mode. The Zicntr test suite is an unprivileged test that does things such as check if instret increments. It should run on RVI32I_Zicsr_Zicntr and also on RV32I_Sm_Zicsr_Zicntr. OK, but the CV32E40P is an odd-ball core that implements more CSRs than specified for RV32IMC_Zicsr_Zicntr, but (probably) not all CSRs specified for RV32IMC_Sm_Zicsr_Zicntr. We can still obtain an RVI20 certification for RV32IMC_Zicsr_Zicntr, but we'll need to initialize mcountinhibit in the RVMODEL_BOOT (or similar) macro. On the other hand, you've discovered that in RV32I_Sm_Zicsr_Zicntr, mcountinhibit could reset to the wrong value and break the instret test. Indeed. That motivated the generation of the previously attached spreadsheet. — Reply to this email directly, view it on GitHub <#1130?email_source=notifications&email_token=AHPXVJQUQBJS3I3OSCT5LGD4SQUGBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGE2DSNZSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16314972>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJT4H2CWM2Q4R5MOWHD4SQUGBAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZRGQ4TOMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jordancarlin]

While we could require RVMODEL_BOOT to do this, I'm uncomfortable having everyone's RVMODEL_BOOT include initialization that a test (or implementation) doesn't need. I'd rather have the test initialize explicitly, using the SBI approach. Note that isn't the full ratified SBI spec, just the minimum to allow a test to initialize an Mmode CSR, and not much else. That support should be pretty cheap (I'm documenting it) basically ILLEGAL_OP handler that checks if it's an Mmode CSR op, writes it into the handler (self modifying code), fence.i, executes it, and returns. That's about a dozen lines of code exclusive of the trap prolog and epilog. Now, if you don't expect to ever see other illegal ops, its half that.

That still doesn't seem like it would work for unpriv tests. Unpriv tests don't even set up a trap handler because mtvec/stvec might not exist, so we can't rely on SBI calls.

[allenjbaum]

How many unpriv tests need any kind of CSR initialization? It it's just zicntr, then requiring mcounterenable to be initialized to all1 doesn't sound horrifying. i do have to say the definition of that register is just wrong, because tests from before it was defined aren't compatible with the introduction of mcounteren definition (because it doesn't default to enabled)

…

On Wed, Mar 25, 2026 at 2:07 PM Jordan Carlin ***@***.***> wrote: While we could require RVMODEL_BOOT to do this, I'm uncomfortable having everyone's RVMODEL_BOOT include initialization that a test (or implementation) doesn't need. I'd rather have the test initialize explicitly, using the SBI approach. Note that isn't the full ratified SBI spec, just the minimum to allow a test to initialize an Mmode CSR, and not much else. That support should be pretty cheap (I'm documenting it) basically ILLEGAL_OP handler that checks if it's an Mmode CSR op, writes it into the handler (self modifying code), fence.i, executes it, and returns. That's about a dozen lines of code exclusive of the trap prolog and epilog. Now, if you don't expect to ever see other illegal ops, its half that. That still doesn't seem like it would work for unpriv tests. Unpriv tests don't even set up a trap handler because mtvec/stvec might not exist, so we can't rely on SBI calls. — Reply to this email directly, view it on GitHub <#1130?email_source=notifications&email_token=AHPXVJQ2IX7Z7RHBKGNXU4T4SRDC7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGE3TKNBYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16317548>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJSNCIFMDQIEE5SD5AT4SRDC7AVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZRG42TIOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MikeOpenHWGroup]

How many unpriv tests need any kind of CSR initialization?

I am not completely sure of this, but here is a (OpenHW core centric) view of RVI20 and MC100 class cores:

• mtvec: in multiple OpenHW cores, the top 24-bits of mtvec are initialized to a top-level primary input. In the CVA6 it is unspecified and it is assumed the software will initialize it.
• mstatus: technically undefined in the unpriv spec, but many cores have a power-on-reset of 0x0000_1800 (MPP==2'b11==M-mode).
• pmpcfgN: these CSRs either don't exist or have no power-on-reset or are reset to top-level parameters defined when the core is compiled/synthesized.
• mscratch: typically (but not always) power-on-reset to 0x0.
• mie: typically (always?) power-on-reset to 0x0.
• mcountinhibit: as we've discussed: our practise is to have a power-on-reset that disables the counters.

There will be others, especially when we consider RVA23 and RVB23 but that is a good start.

[jordancarlin]

How many unpriv tests need any kind of CSR initialization?

I am not completely sure of this, but here is a (OpenHW core centric) view of RVI20 and MC100 class cores:

Comments on each CSR inline. Note that most of these are only needed for priv tests, not unpriv tests.

• mtvec: in multiple OpenHW cores, the top 24-bits of mtvec are initialized to a top-level primary input. In the CVA6 it is unspecified and it is assumed the software will initialize it.

For priv tests only, mtvec is set during the test setup to point at our trap handler. If mtvec is not writable, then our trap handler code is instead copied to the address that mtvec points at (assuming that memory is writable). If neither of those work, the test will fail because we can't load our trap handler. For unpriv tests, mtvec is not used.

• mstatus: technically undefined in the unpriv spec, but many cores have a power-on-reset of 0x0000_1800 (MPP==2'b11==M-mode).

We initialize mstatus when needed (to enable floating point, switch modes, etc.). We don't depend on its initial value. This one is written to even for unpriv tests because we need to enable the floating point unit. We may need to revisit this as we work to separate M-mode concerns.

• pmpcfgN: these CSRs either don't exist or have no power-on-reset or are reset to top-level parameters defined when the core is compiled/synthesized.

We currently treat them as writable if they are implemented and will set up one region as a background covering all memory to enable access (except for PMP tests which obviously do quite a bit more with them).

• mscratch: typically (but not always) power-on-reset to 0x0.

For priv tests only, we initialize mscratch to point at a scratch area of memory for the trap handler to use. For unpriv tests, mscratch is not used.

• mie: typically (always?) power-on-reset to 0x0.

I think right now we assume a reset value of 0x0 and enable it when we are testing interrupts.

• mcountinhibit: as we've discussed: our practise is to have a power-on-reset that disables the counters.

As discussed elsewhere, this one seems like we might need to require users to enable the counters in their RVMODEL_BOOT macro. This is one of the few that is needed for unpriv tests.

There will be others, especially when we consider RVA23 and RVB23 but that is a good start.

[allenjbaum]

I think that CSC should define that tests start running at the highest privilege level below Mmode (or Mmode for an Mmode only core), and that Mmode boot code must set any initial values of Mmode CSRs to enable tests to be run. E.g. mstatus.PP must be set to the value described above, mepc must be set to the start of the test (as defined by the label rvtest_init), mtvec must be set to the start of the RVMODEL defined mmode trap handler medeleg should be set to prevent SBI calls (ECALL) from being delegated mstatus.mie must be set to 0 to prevent unexpected interrupts from happening before an sret is executed to start a test The Mmode trap handler must - have the functionality to emulate ANY Mmode CSR reads&writes that a test depends on via an SBI call, - must handle the SBI call (ECALL) that implements the above CSR accesses - must handle an alternate SBI call (typically an specific illegal op) when enabled (via an SBI call, so ECALL can be tested when delegated) - must handle any other defined RVMODEL macros (e.g. HALT, print sucess/fail messages, etc) E.g. a test of counters must be able to set all mcounteren bits corresponding to implemented counters - and to clear them according to the provided implementation defined behaviors ( so, they could be RdOnly 0, which indicates that no counters exist, or all RdOnly1 which means all exist AND Smode has access to all. Or mcounteren may not exist, and an SBI call that attempts to set all the bits will just return the appropriate constant value indicating which can be manipulated by Smode That emulation is entirely the responsibility of the RVMODEL Mmode trap handler. If it gets something wrong - e.g. if it doesn't implement what the declared DUT implementation defined parameter is - then tests will fail, and rightly so.

…

On Wed, Apr 1, 2026 at 8:22 AM Jordan Carlin ***@***.***> wrote: How many unpriv tests need any kind of CSR initialization? I am not completely sure of this, but here is a (OpenHW core centric) view of RVI20 and MC100 class cores: Comments on each CSR inline. Note that most of these are only needed for *priv* tests, not *unpriv* tests. - *mtvec*: in multiple OpenHW cores, the top 24-bits of mtvec are initialized to a top-level primary input. In the CVA6 it is unspecified and it is assumed the software will initialize it. For priv tests only, mtvec is set during the test setup to point at our trap handler. If mtvec is not writable, then our trap handler code is instead copied to the address that mtvec points at (assuming that memory is writable). If neither of those work, the test will fail because we can't load our trap handler. For unpriv tests, mtvec is not used. - *mstatus*: technically undefined in the unpriv spec, but many cores have a power-on-reset of 0x0000_1800 (MPP==2'b11==M-mode). We initialize mstatus when needed (to enable floating point, switch modes, etc.). We don't depend on its initial value. This one is written to even for unpriv tests because we need to enable the floating point unit. We may need to revisit this as we work to separate M-mode concerns. - *pmpcfgN*: these CSRs either don't exist or have no power-on-reset or are reset to top-level parameters defined when the core is compiled/synthesized. We currently treat them as writable if they are implemented and will set up one region as a background covering all memory to enable access (except for PMP tests which obviously do quite a bit more with them). - *mscratch*: typically (but not always) power-on-reset to 0x0. For priv tests only, we initialize mscratch to point at a scratch area of memory for the trap handler to use. For unpriv tests, mscratch is not used. - *mie*: typically (always?) power-on-reset to 0x0. I think right now we assume a reset value of 0x0 and enable it when we are testing interrupts. - *mcountinhibit*: as we've discussed: our practise is to have a power-on-reset that *disables* the counters. As discussed elsewhere, this one seems like we might need to require users to enable the counters in their RVMODEL_BOOT macro. This is one of the few that is needed for unpriv tests. There will be others, especially when we consider RVA23 and RVB23 but that is a good start. — Reply to this email directly, view it on GitHub <#1130?email_source=notifications&email_token=AHPXVJRNM2WDON2HWOB3XSD4TUX4ZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRUGEYDOMZXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16410737>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTTHFT3BONMU2A4R3L4TUX4ZAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBRGA3TGNY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MikeOpenHWGroup]

I think that CSC should define that tests start running at the highest privilege level below Mmode (or Mmode for an Mmode only core), and that Mmode boot code must set any initial values of Mmode CSRs to enable tests to be run.

FWIW, I agree with this stance.

[allenjbaum]

There is a consequence of this I think needs some discussion. First, we need distinguish between setting a CSR value, and initializing a CSR value. If tests in general don't need to touch an Mmode CSR to run, then only the tests that need the CSR set a specific way should set it - explicitly, using a CSR update SBI call that all DUTs must provide (which could be a reference SBI provided by the CSC) An obvious consequence is that any test that needs a field set multiple ways must use the SBI call. Tests still might need a CSR field initialized one way, or another way, or may not care. I propose that the rule be: - if either most tests need it initialized one way or don't care, and only some tests need it set or initialized another way, then it's fine to have RVMODEL_BOOT initialize it the way most tests need it initialized, and only the tests that need it initialized some other way will use the SBI calls. (and this must be documented, of course) There's clearly a judgement call here about the value of "most", but I suspect it will rarely be the case that it will even need a judgement call. Because of the amount of work needed to identify when something should be in RVMODEL_BOOT, and the needs of keeping it up-to-date, the default should be that we should try to minimize how often RVMODEL_BOOT needs to initialize CSR values.

…

On Mon, Apr 6, 2026 at 10:08 AM Mike Thompson ***@***.***> wrote: I think that CSC should define that tests start running at the highest privilege level below Mmode (or Mmode for an Mmode only core), and that Mmode boot code must set any initial values of Mmode CSRs to enable tests to be run. FWIW, I agree with this stance. — Reply to this email directly, view it on GitHub <#1130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQA6ZG6KRTYAS4VIF34UPP7RAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGYYTONY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davidharrishmc]

Agreed about needing a SBI call. Good question about whether CSRs should be initialized all at once or only when they affect the result. Jordan and I have a draft doing it all at once, but I see your point too. It would raise a challenge for a test such as Zicntr, which tests unprivileged accesses to counters and might be running in U-mode depending on our choice of the boot process. For some DUTs, we would need to initialize mcounteren and scounteren for Zicntr to run. Other DUTs wouldn’t even implement those CSRs. I’d rather the code to initialize be in a common place that only has to be modified once, rather than scattered around at the beginning of Zicntr and other unpriv tests. Somebody (Umer?) suggested running at the lowest available privilege level (U-mode if it exists, or the possibly nonconforming M-mode from boot if no U-mode), for tests that don’t explicilty aim to test M, S, or U. Jordan and I like that approach, and have sketched out how it works. It pushes tests down to the priv mode where they are most likely to be running on a real platform - U seems more interesting than S when priv doesn’t matter. David

…

On Apr 6, 2026, at 10:38 AM, Allen Baum ***@***.***> wrote: There is a consequence of this I think needs some discussion. First, we need distinguish between setting a CSR value, and initializing a CSR value. If tests in general don't need to touch an Mmode CSR to run, then only the tests that need the CSR set a specific way should set it - explicitly, using a CSR update SBI call that all DUTs must provide (which could be a reference SBI provided by the CSC) An obvious consequence is that any test that needs a field set multiple ways must use the SBI call. Tests still might need a CSR field initialized one way, or another way, or may not care. I propose that the rule be: - if either most tests need it initialized one way or don't care, and only some tests need it set or initialized another way, then it's fine to have RVMODEL_BOOT initialize it the way most tests need it initialized, and only the tests that need it initialized some other way will use the SBI calls. (and this must be documented, of course) There's clearly a judgement call here about the value of "most", but I suspect it will rarely be the case that it will even need a judgement call. Because of the amount of work needed to identify when something should be in RVMODEL_BOOT, and the needs of keeping it up-to-date, the default should be that we should try to minimize how often RVMODEL_BOOT needs to initialize CSR values. On Mon, Apr 6, 2026 at 10:08 AM Mike Thompson ***@***.***> wrote: > I think that CSC should define that tests start running at the highest > privilege level below Mmode (or Mmode for an Mmode only core), and that > Mmode boot code must set any initial values of Mmode CSRs to enable tests > to be run. > > FWIW, I agree with this stance. > > — > Reply to this email directly, view it on GitHub > <#1130 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHPXVJQA6ZG6KRTYAS4VIF34UPP7RAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGYYTONY> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA3Y5IYT7DUX5SQSP5ZD4UPTQ7AVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGY2TCNA>. You are receiving this because you commented.

[allenjbaum]

Isn't that Zicntr just an issue of handling WARL fields correctly? IF the reference has the same number of counters, and only allows certain values to be written to mcounteren, then both reference and DUT will have the same behavior. On Mon, Apr 6, 2026 at 10:54 AM David Harris ***@***.***> wrote:

…

Agreed about needing a SBI call. Good question about whether CSRs should be initialized all at once or only when they affect the result. Jordan and I have a draft doing it all at once, but I see your point too. It would raise a challenge for a test such as Zicntr, which tests unprivileged accesses to counters and might be running in U-mode depending on our choice of the boot process. For some DUTs, we would need to initialize mcounteren and scounteren for Zicntr to run. Other DUTs wouldn’t even implement those CSRs. I’d rather the code to initialize be in a common place that only has to be modified once, rather than scattered around at the beginning of Zicntr and other unpriv tests. Somebody (Umer?) suggested running at the lowest available privilege level (U-mode if it exists, or the possibly nonconforming M-mode from boot if no U-mode), for tests that don’t explicilty aim to test M, S, or U. Jordan and I like that approach, and have sketched out how it works. It pushes tests down to the priv mode where they are most likely to be running on a real platform - U seems more interesting than S when priv doesn’t matter. David > On Apr 6, 2026, at 10:38 AM, Allen Baum ***@***.***> wrote: > > > There is a consequence of this I think needs some discussion. > First, we need distinguish between setting a CSR value, and initializing a > CSR value. > If tests in general don't need to touch an Mmode CSR to run, > then only the tests that need the CSR set a specific way should set it > - explicitly, using a CSR update SBI call that all DUTs must provide (which > could be a reference SBI provided by the CSC) > > An obvious consequence is that any test that needs a field set multiple > ways must use the SBI call. > > Tests still might need a CSR field initialized one way, or another way, or > may not care. I propose that the rule be: > - if either most tests need it initialized one way or don't care, and only > some tests need it set or initialized another way, > then it's fine to have RVMODEL_BOOT initialize it the way most tests > need it initialized, > and only the tests that need it initialized some other way will use > the SBI calls. (and this must be documented, of course) > > There's clearly a judgement call here about the value of "most", > but I suspect it will rarely be the case that it will even need a judgement > call. > > Because of the amount of work needed to identify when something should be > in RVMODEL_BOOT, and the needs of keeping it up-to-date, the default should > be that we should try to minimize how often RVMODEL_BOOT needs to > initialize CSR values. > > On Mon, Apr 6, 2026 at 10:08 AM Mike Thompson ***@***.***> > wrote: > > > I think that CSC should define that tests start running at the highest > > privilege level below Mmode (or Mmode for an Mmode only core), and that > > Mmode boot code must set any initial values of Mmode CSRs to enable tests > > to be run. > > > > FWIW, I agree with this stance. > > > > — > > Reply to this email directly, view it on GitHub > > < #1130 (comment)>, > > or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AHPXVJQA6ZG6KRTYAS4VIF34UPP7RAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGYYTONY> > > . > > You are receiving this because you were mentioned.Message ID: > > ***@***.***> > > > — > Reply to this email directly, view it on GitHub < #1130 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA3Y5IYT7DUX5SQSP5ZD4UPTQ7AVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGY2TCNA>. > You are receiving this because you commented. > — Reply to this email directly, view it on GitHub <#1130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRZIW65MIGEW5Y7CQD4UPVPFAVCNFSM6AAAAACW62ECNGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBWGY3DMMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>