Clarify CLIC/CLINT mode interaction

[JamesKenneyImperas]

A change to the specification on 5th July includes this text:

In CLIC mode, xtvec.submode and xtvec.mode in lower privilege modes are writeable but appear to be 0000 and 11 respectively when read in that mode.

This doesn't seem to quite tie up with what I think is the associated comment in the Task Group minutes of 5th July, which says:

Claified xtvec.mode note in spec. Tried to be consistent with sepc[1] behavior when toggling misa.c where stvec.mode/utvec.mode can be written, but always behave as 000011 when mtvec.mode is 000011.

I think having these fields always behave as 000011 makes sense, but the specification implies to me that written values are respected but if the value is read (e.g. by csrr) the returned value is 000011, which is not the same thing. I don't know if this is the intended design or not - can you please clarify? Having bits that are writeable-but-hidden-from-read feels like a bad idea: for example, code that is attempting to save and restore CSR state could unintentionally modify hidden CSR state without knowing it.

Thanks.

[dansmathers]

The sepc privileged spec text we were trying to be consistent with is: If an implementation allows IALIGN to be either 16 or 32 (by changing CSR misa, for example), then, whenever IALIGN=32, bit sepc[1] is masked on reads so that it appears to be 0. This masking occurs also for the implicit read by the SRET instruction. Though masked, sepc[1] remains writable when IALIGN=32.

so as you say, those bits are writeable-but-hidden-from-read.

https://github.com/riscv/riscv-isa-manual/issues/332

I will bring this issue up in our next TG meeting and try to add more comments to this issue.

[JamesKenneyImperas]

Thanks Dan, and also for pointing me at that issue, which is a very similar complaint.

[JamesKenneyImperas]

Related to this, what happens if mtvec indicates CLINT mode and stvec indicates CLIC mode? The specification covers the case when a higher-level privilege level indicates CLIC mode and a lower level CLINT mode, but not the other way round, as far as I can see. Although this is a misprogramming, I think the resulting behavior ought to be be defined.

Thanks.

[JamesKenneyImperas]

Sorry to bang on about this, but I think there is another issue here. Section 5.7 says (about writing to xtvec):

When basic mode is written to xtvec, the new xcause state fields (mhinv and mpil) are zeroed.

Is this true in the case of a write to stvec when mtvec indicates CLIC mode? If not, what happens if mtvec is subsequently written to indicate basic mode as well? Does this zero scause.sinhv and scause.spil, or not?

(Incidentally, section 5.7 is mixing up generic references (e.g. xtvec) and specific references (e.g. mhinv) so could do with a bit of a tidy-up; also mhinv should be minhv.)

Thanks.

[dansmathers]

If in CLINT mode, should not see the new stuff. will try to clean up the text. if mtvec is in CLINT mode, all other modes will be in CLINT mode as well. We will add generic text that switching CLINT/CLIC modes does not modify the state of the csrs, but just modifies what is seen and how it is used.

[dansmathers]

instead of using the word "seen" use implicit read in the text.

[dansmathers]

still need to mention that CLINT can't have lower priv with CLIC. check spec to see if CLINT/CLIC mode commments can be put in single area.

[kasanovic]

Above commits addressed this issue.

[JamesKenneyImperas]

Section 5.8 has this sentence:

For backwards compatibility in systems supporting both CLINT and CLIC modes, when switching to CLINT mode the new CLIC xcause state fields (xinhv and xpil) are zeroed. The other new CLIC xcause fields, xpp and xpie, appear as zero in the xcause CSR but the corresponding state bits in the mstatus register are not cleared.

Section 5.4 specifies that whether a privilege level is operating in CLINT or CLIC mode is defined by mtvec only.

Does this mean that when mtvec is switched from CLIC mode to CLINT mode, xinhv and xpil fields for all privilege levels are zeroed?

[dansmathers]

yes. that is the implication that all xinhv, xpil fields for all priv levels are zeroed when switching from all CLIC to all CLINT modes. For 1.0, we are only planning on only supporting all CLIC or all CLINT.

Although future CLIC versions may allow privileges to have different xtvec.mode settings, for now all privilege modes must run in either CLIC mode or all privilege modes must run in non-CLIC mode. These constraints might change if there are future additions to the CLIC or other new interrupt controller specs.

As the note in the spec says, this may not be true for future post 1.0 specs. Is this clarification enough or are you looking for a clarification added to the spec?

[JamesKenneyImperas]

Hi Dan,

Yes, I think this should be clarified. The definition of x in the context of section 5.8 is the new interrupt’s privilege mode (see the fourth paragraph of this section) which isn't the same thing as what you've said here.

James.

[dansmathers]

(reopening for better tracking) Can you spell out specifically what is different from what I've said here? I think I'm missing what you are getting at and want clarified. Maybe you could provide an example of text you think would be more clear?

The point is that in CLINT mode, those fields don't exist, hence zeroed. so if all priv modes are CLINT, they are all zeroed. if all modes are CLIC, the fields exist in all priv modes and are not zeroed. Only all priv mode CLINT or all priv modes CLIC will be supported for 1.0.

[JamesKenneyImperas]

Hi Dan,

My confusion is that the meaning of x changes implicitly from the target privilege mode to all interrupt target privilege modes in this section. The previous paragraph says:

The CSR xepc is set to the PC of the interrupted application code or preempted interrupt handler, while the xcause register now captures the previous privilege mode (pp), interrupt level (pil) and interrupt enable (pie), as well as the id of the interrupt in exccode.

This clearly is talking about the effect on the target execution model only. Then the next paragraph says what I included above:

For backwards compatibility in systems supporting both CLINT and CLIC modes, when switching to CLINT mode the new CLIC xcause state fields (xinhv and xpil) are zeroed. The other new CLIC xcause fields, xpp and xpie, appear as zero in the xcause CSR but the corresponding state bits in the mstatus register are not cleared.

Adding something that explicitly says that in 1.0 changing from CLIC to CLINT mode in mtvec will therefore clear xinhv and xpil in all xcause CSRs would help, I think, but if you don't think it's necessary, I'll accept that, in which case please close this issue.

[kasanovic]

Closed with https://github.com/riscv/riscv-fast-interrupt/pull/288