Date   

Re: Question about supervisor interrupt in M mode

Scott Johnson
 

Oscar, what you are missing is that STI, despite its name, is not for a lower-privilege mode when mideleg[5]==0. In that case the STI is destined for M-mode and therefore can be taken in any privilege mode.

To correct your statement: When a hart is executing in M mode, supervisor timer interrupt is disabled if mideleg[5]==1.


Re: Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear Allen,
Thank you for your replay.
How to understand next sentence: 

"Interrupts for higher-privilege modes, y>x, are always globally enabled regardless of the setting of the global yIE 
bit for the higher-privilege mode.”

Is it should be interpreted as:
“When xIE = 1,  Interrupts for higher-privilege modes, y>x, are always globally enabled regardless of the setting of the global yIE 
bit for the higher-privilege mode.”?

Regards,
Oscar Jupp

---- Replied Message ----
From Allen Baum<allen.baum@...>
Date 11/29/2022 21:24
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about supervisor interrupt in M mode
I think (and will be corrected if wrong) that the sentence should be interpreted as
When xIE=0, Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."


On Tue, Nov 29, 2022 at 3:50 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, if the supervisor timer interrupt (STI) is delegated to S-mode by setting mideleg[5], STIs  will not be taken when executing in M-mode. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Re: Question about supervisor interrupt in M mode

Allen Baum
 

I think (and will be corrected if wrong) that the sentence should be interpreted as
When xIE=0, Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."


On Tue, Nov 29, 2022 at 3:50 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, if the supervisor timer interrupt (STI) is delegated to S-mode by setting mideleg[5], STIs  will not be taken when executing in M-mode. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Question about supervisor interrupt in M mode

Oscar Jupp
 

Dear architect, 
Priv spec section 3.1.6.1 write: 
When a hart is executing in privilege mode x, interrupts are globally enabled when xIE=1 and globally disabled when xIE=0. Interrupts for lower-privilege modes, w<x are always globally disabled regardless of the setting of any global wIE bit for the lower-privilege mode."

So I think when a hart is executing in M mode, supervisor timer interrupt is disabled.

However, Priv spec section 3.1.8 write: 
For example, if the supervisor timer interrupt (STI) is delegated to S-mode by setting mideleg[5], STIs  will not be taken when executing in M-mode. By contrast, if mideleg[5] is clear, STIs can be taken  in any mode and regardless of current mode will transfer control to M-mode.

Is it contradictory.

Regards,
Oscar Jupp



Re: Question about mip and vsip

John Hauser
 

Greg Favor wrote:
The vsip CSR - as with all vs* CSRs - is only accessible by HS-mode (and
M-mode). As the vsip definition says, "When V=1, vsip and vsie substitute
for the usual sip and sie, so instructions that normally read or modify
sip/sie actually access vsip/vsie instead."
To emphasize Greg's point, the next sentence says, "When V=1, an
attempt to read or write a VS CSR directly by its own separate CSR
address causes a virtual instruction exception."

Oscar Jupp asked:
2.  Are the fields SEIP,SSIP,STIP in vsip real-only ? Can VS-mode
software modify these bit fields?
By the text quoted above, attempting to access vsip directly from VS
mode raises a virtual instruction exception. (V = 1 in VS mode.)

What about accessing sip from VS mode, which is really vsip? Because
the whole purpose of VS mode is to be a virtual S mode, the general
default assumption should be that VS mode provides an equivalent
execution environment as S mode. Therefore, what VS mode sees of
sip is what the Privileged Architecture says is true of sip in the
Supervisor-Level chapter (Section 4.1.3, "Supervisor Interrupt
Registers (sip and sie)"): "If implemented, SEIP is read-only
in sip...." "If implemented, STIP is read-only in sip...." "If
implemented, SSIP is writable in sip...."

- John Hauser


Re: Question about mip and vsip

Oscar Jupp
 

Thanks for Allen and Greg!
I learn a lot from you. 


---- Replied Message ----
From Allen Baum<allen.baum@...>
Date 11/27/2022 15:07
To Greg Favor<gfavor@...>
Cc jupposcar<jupposcar@...> ,
tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about mip and vsip
Without a deep understanding of these particular bits (and Greg will correct me if I'm wrong) there are some general rules that should apply
(I am unaware of any exceptions to this off the top of my head, but if they are anywhere, they'd probably be in the interrupt and hypervisor CSRs): 
 A bit that is RW accessible to a lower privilege mode should always be RW at a higher privilege mode (though it may be accessed at a different address because of the way hypervisor extension works)
  If the CSR is accessible to the accessing mode at all, and is not in the ReadOnly CSR ranges, then
  if a bit is described as an alias,      then it should be read/write if they are read/write at the higher privilege level
  if a bit is described as an shadow, then it should be read-only  even if they are read/write at the higher privilege level
  A CSR which is described as a "restricted view" would have some bits that aliased at a higher privilege level, and be read-only zero at lower privilege levels.


On Sat, Nov 26, 2022 at 10:56 PM Greg Favor <gfavor@...> wrote:
On Sat, Nov 26, 2022 at 8:41 PM jupposcar <jupposcar@...> wrote:
1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” 
But I don’t know they are read-only aliases ? or read-write aliases ? In other word, Can the CSR instruction  with the CSR number 0x344 (mip) modify these bits?

Per Priv section 2.2, 0x344 is read/write.  And hip is also read-write.  So the mip aliases of these hip bits are also read/write in mip.
 
Or only CSR instruction with the CSR number 0x644 (hip) can modify these bits?

2. The ISA said : “If implemented, SEIP is read-only in sip."(Priv section 4.3.1)
It means sip.SEIP is read-only for S-mode. Similarly, is vsip.SEIP read-only for VS-mode ?

First, I think you mean section 5.1.3 in the latest draft of the Priv spec.  And yes, you're correct.
 
Greg


Re: Question about mip and vsip

Greg Favor
 

I believe I would agree with what Allen said.  Regarding shadows, note that Priv section 2.1 says:

CSRs that are read-only at some lower privilege level are shadowed into separate CSR addresses if they are made read-write at a higher privilege level. This avoids trapping permitted lower-privilege accesses while still causing traps on illegal accesses. Currently, the counters are the only shadowed CSRs.  

Greg

On Sat, Nov 26, 2022 at 11:07 PM Allen Baum <allen.baum@...> wrote:
Without a deep understanding of these particular bits (and Greg will correct me if I'm wrong) there are some general rules that should apply
(I am unaware of any exceptions to this off the top of my head, but if they are anywhere, they'd probably be in the interrupt and hypervisor CSRs): 
 A bit that is RW accessible to a lower privilege mode should always be RW at a higher privilege mode (though it may be accessed at a different address because of the way hypervisor extension works)
  If the CSR is accessible to the accessing mode at all, and is not in the ReadOnly CSR ranges, then
  if a bit is described as an alias,      then it should be read/write if they are read/write at the higher privilege level
  if a bit is described as an shadow, then it should be read-only  even if they are read/write at the higher privilege level
  A CSR which is described as a "restricted view" would have some bits that aliased at a higher privilege level, and be read-only zero at lower privilege levels.


On Sat, Nov 26, 2022 at 10:56 PM Greg Favor <gfavor@...> wrote:
On Sat, Nov 26, 2022 at 8:41 PM jupposcar <jupposcar@...> wrote:
1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” 
But I don’t know they are read-only aliases ? or read-write aliases ? In other word, Can the CSR instruction  with the CSR number 0x344 (mip) modify these bits?

Per Priv section 2.2, 0x344 is read/write.  And hip is also read-write.  So the mip aliases of these hip bits are also read/write in mip.
 
Or only CSR instruction with the CSR number 0x644 (hip) can modify these bits?

2. The ISA said : “If implemented, SEIP is read-only in sip."(Priv section 4.3.1)
It means sip.SEIP is read-only for S-mode. Similarly, is vsip.SEIP read-only for VS-mode ?

First, I think you mean section 5.1.3 in the latest draft of the Priv spec.  And yes, you're correct.
 
Greg


Re: Question about mip and vsip

Allen Baum
 

Without a deep understanding of these particular bits (and Greg will correct me if I'm wrong) there are some general rules that should apply
(I am unaware of any exceptions to this off the top of my head, but if they are anywhere, they'd probably be in the interrupt and hypervisor CSRs): 
 A bit that is RW accessible to a lower privilege mode should always be RW at a higher privilege mode (though it may be accessed at a different address because of the way hypervisor extension works)
  If the CSR is accessible to the accessing mode at all, and is not in the ReadOnly CSR ranges, then
  if a bit is described as an alias,      then it should be read/write if they are read/write at the higher privilege level
  if a bit is described as an shadow, then it should be read-only  even if they are read/write at the higher privilege level
  A CSR which is described as a "restricted view" would have some bits that aliased at a higher privilege level, and be read-only zero at lower privilege levels.


On Sat, Nov 26, 2022 at 10:56 PM Greg Favor <gfavor@...> wrote:
On Sat, Nov 26, 2022 at 8:41 PM jupposcar <jupposcar@...> wrote:
1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” 
But I don’t know they are read-only aliases ? or read-write aliases ? In other word, Can the CSR instruction  with the CSR number 0x344 (mip) modify these bits?

Per Priv section 2.2, 0x344 is read/write.  And hip is also read-write.  So the mip aliases of these hip bits are also read/write in mip.
 
Or only CSR instruction with the CSR number 0x644 (hip) can modify these bits?

2. The ISA said : “If implemented, SEIP is read-only in sip."(Priv section 4.3.1)
It means sip.SEIP is read-only for S-mode. Similarly, is vsip.SEIP read-only for VS-mode ?

First, I think you mean section 5.1.3 in the latest draft of the Priv spec.  And yes, you're correct.
 
Greg


Re: Question about mip and vsip

Greg Favor
 

On Sat, Nov 26, 2022 at 8:41 PM jupposcar <jupposcar@...> wrote:
1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” 
But I don’t know they are read-only aliases ? or read-write aliases ? In other word, Can the CSR instruction  with the CSR number 0x344 (mip) modify these bits?

Per Priv section 2.2, 0x344 is read/write.  And hip is also read-write.  So the mip aliases of these hip bits are also read/write in mip.
 
Or only CSR instruction with the CSR number 0x644 (hip) can modify these bits?

2. The ISA said : “If implemented, SEIP is read-only in sip."(Priv section 4.3.1)
It means sip.SEIP is read-only for S-mode. Similarly, is vsip.SEIP read-only for VS-mode ?

First, I think you mean section 5.1.3 in the latest draft of the Priv spec.  And yes, you're correct.
 
Greg


Re: Question about mip and vsip

Oscar Jupp
 

Dear Greg,
Thanks for your reply.
1. You said : “Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.” 
But I don’t know they are read-only aliases ? or read-write aliases ? In other word, Can the CSR instruction  with the CSR number 0x344 (mip) modify these bits? Or only CSR instruction with the CSR number 0x644 (hip) can modify these bits?

2. The ISA said : “If implemented, SEIP is read-only in sip."(Priv section 4.3.1)
It means sip.SEIP is read-only for S-mode. Similarly, is vsip.SEIP read-only for VS-mode ?


---- Replied Message ----
From Greg Favor<gfavor@...>
Date 11/27/2022 06:16
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about mip and vsip
On Sat, Nov 26, 2022 at 4:38 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect,
CSR mip and vsip are both WARL. But SPEC did not specify that :
1.  Are the fields VSEIP,VSSIP,VSTIP in mip real-only ? Can M-mode software modify these bit fields?

Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.

2.  Are the fields SEIP,SSIP,STIP in vsip real-only ? Can VS-mode software modify these bit fields?

The vsip CSR - as with all vs* CSRs - is only accessible by HS-mode (and M-mode).  As the vsip definition says, "When V=1, vsip and vsie substitute for the usual sip and sie, so instructions that normally read or modify sip/sie actually access vsip/vsie instead."

In other words, VS-mode software (just like S/HS-mode software) has read/write access to sip, but in the case of VS-mode software (i.e. V=1) it actually accesses vsip and not sip.

Greg


Re: Question about mip and vsip

Greg Favor
 

On Sat, Nov 26, 2022 at 4:38 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect,
CSR mip and vsip are both WARL. But SPEC did not specify that :
1.  Are the fields VSEIP,VSSIP,VSTIP in mip real-only ? Can M-mode software modify these bit fields?

Priv section 9.4.3 defines these bits as aliases (of bits in hip), so yes - M-mode software can modify these bits.

2.  Are the fields SEIP,SSIP,STIP in vsip real-only ? Can VS-mode software modify these bit fields?

The vsip CSR - as with all vs* CSRs - is only accessible by HS-mode (and M-mode).  As the vsip definition says, "When V=1, vsip and vsie substitute for the usual sip and sie, so instructions that normally read or modify sip/sie actually access vsip/vsie instead."

In other words, VS-mode software (just like S/HS-mode software) has read/write access to sip, but in the case of VS-mode software (i.e. V=1) it actually accesses vsip and not sip.

Greg


Question about mip and vsip

Oscar Jupp
 

Dear architect,
CSR mip and vsip are both WARL. But SPEC did not specify that :
1.  Are the fields VSEIP,VSSIP,VSTIP in mip real-only ? Can M-mode software modify these bit fields?
2.  Are the fields SEIP,SSIP,STIP in vsip real-only ? Can VS-mode software modify these bit fields?

Regards,
Oscar Jupp


AR (Architecture Review) Committee minutes for 11/22/22

Greg Favor
 

We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RISC-V arch extensions that have been submitted for official AR (or for prelim review).  Here are this week's minutes.

Minutes from AR Committee meeting on 11/22/22
  • Vector Crypto.
    • The question was asked to AR as to what would be considered a sufficient PoC to validate the completeness and correctness of the proposed arch spec.

    • Currently the instructions have been modeled in Spike, and various crypto tests have been run - producing correct results.  This was largely considered to be sufficient to satisfy the architecture PoC requirement.

    • But one notable exception was called out - for the instructions that require VLEN=256 to run with LMUL=1.  On VLEN=128 designs, software will need to use LMUL=2 to create effectively 256-bit-wide vector registers - which halves the number of available registers.  Hence a request for the TG to verify that 16 vector registers (vector register groups to be precise) are sufficient to implement fully performant routines using these instructions.
  • IOMMU detailed architecture review.
    • The in-depth review continues and is down to the final chapter of the spec.
  • P extension.
    • Work has been paused (on putting together a proposed spec for a baseline RISC-V P extension) for a while due to priority being given to completing arch review of the IOMMU spec.  Focus is expected to shift back after the RISC-V Summit and December holidays.
  • Zicondops.
    • An inquiry to be sent to Ved and Ken about the latest status of this fast track extension (which is targeted for inclusion in the RVA23 ISA profiles).

  • BFloat16
    • A fast track extension proposal is being put together to add BFloat16 support to the ISA and a question was put to the AR Committee regarding the handling of details like NaN payloads and subnormals - especially given that other architectures (e.g. Intel, Nvidia, ARM) have not made the exact same choices in these areas.

    • The general AR feedback is that it would be best for RISC-V to match one of the other architectures with regards to these details (versus doing something yet again different from everyone else).  Further, following ARM's choices is suggested as this is most consistent with RISC-V FP architecture.

    • Flushing subnormals to zero was proposed, but the informal AR feedback is to require subnormal handling (as part of following the preceding bullet point).


AR (Architecture Review) Committee minutes for 11/15

Greg Favor
 

We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RISC-V arch extensions that have been submitted for official AR (or for prelim review).  

Last week there was no AR Committee meeting due to some members being out of town.  But the following items of AR business took place over email:

"Minutes" for the week ending 11/15/22
  • IOMMU detailed architecture review.
    • The in-depth review continues - with feedback continuing to be posted as IOMMU GitHub issues - and looks to be nearing in on the final stretch.
  • Further AR feedback on Vector Crypto spec previously submitted for arch review.
    • About nine or so current deficiencies in the exact instruction definitions (aka pseudo-code) were provided as examples of the general point that the spec - before it can be officially Frozen - needs to be a complete and standalone spec of the arch extension (e.g. without external dependencies on other documents or reference models to provide detailed instruction definitions).  The TG acknowledged that they were still working on completing the spec and are looking to complete it soon.  A final and complete spec will be submitted for final AR - which hopefully should proceed fairly smoothly at this point.


Re: Quetion about SSTC

Greg Favor
 

On Mon, Nov 21, 2022 at 7:09 PM jupposcar <jupposcar@...> wrote:
Please clarify what kind of exceptions are generated by U and VU? I think when V=0, it is an illegal instruction exception, and when V=1 is a virtual instruction exception. Is it correct?

See Priv section 9.6.1 for a description of the general rule for when to raise a virtual instruction versus illegal instruction exception.

Greg


Re: Quetion about SSTC

Oscar Jupp
 

Dear architect, 
Thank you for your reply.
Please clarify what kind of exceptions are generated by U and VU? I think when V=0, it is an illegal instruction exception, and when V=1 is a virtual instruction exception. Is it correct?

Regards,
Oscar Jupp


---- Replied Message ----
From Greg Favor<gfavor@...>
Date 11/22/2022 01:13
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Quetion about SSTC
Per Priv section 2.1 and Table 2.1, the CSR numbers encodes the lowest privilege level that can access the CSR.  That level and all higher levels can access the CSR.

So the first row of red should be M, HS; and the second row of red should be M, HS, VS.  In general, these CSRs are never accessible by U/VU privilege modes.

Greg

On Mon, Nov 21, 2022 at 5:35 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect,
The stimecmp / vstimecmp” Extension said:
"When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode
raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its
defined behavior as if this extension is not implemented. 
When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp)
when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this
extension is not implemented."


So I made the following table to show the conditions of accessing stimecmp and vstimecmp when menvcfg.STCE, henvcfg.STCE and V take different values.
The blue words in the table are the access conditions I understand. If there are any mistakes, please point it out for me.
The red words in the table are not clear to me, please clarify what is the access conditions of each privilege level.

menvcfg.STCE
henvcfg.STCE
V
Access the CSR with number 0x14D(stimecmp)
Access the CSR with number 0x24D(vstimecmp)
0
0(read-only zero)
0 or 1
Except M-level can access, other privilege level access will generate illegal instruction exception.
1
0
0
M,S(HS), and U can all access
M, S(HS), and U ????
1
0
1
VS and VU will generate virtual instruction exception
VS and VU will generate virtual instruction exception
1
1
0
M,S(HS), and U level can all access
M,S(HS) can access,U-level will generate illegal instruction exception.
1
1
1
VS and VU????????
VS and VU will generate virtual instruction exception

Regards,
Oscar Jupp


Re: Quetion about SSTC

Greg Favor
 

Per Priv section 2.1 and Table 2.1, the CSR numbers encodes the lowest privilege level that can access the CSR.  That level and all higher levels can access the CSR.

So the first row of red should be M, HS; and the second row of red should be M, HS, VS.  In general, these CSRs are never accessible by U/VU privilege modes.

Greg

On Mon, Nov 21, 2022 at 5:35 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect,
The stimecmp / vstimecmp” Extension said:
"When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode
raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its
defined behavior as if this extension is not implemented. 
When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp)
when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this
extension is not implemented."


So I made the following table to show the conditions of accessing stimecmp and vstimecmp when menvcfg.STCE, henvcfg.STCE and V take different values.
The blue words in the table are the access conditions I understand. If there are any mistakes, please point it out for me.
The red words in the table are not clear to me, please clarify what is the access conditions of each privilege level.

menvcfg.STCE
henvcfg.STCE
V
Access the CSR with number 0x14D(stimecmp)
Access the CSR with number 0x24D(vstimecmp)
0
0(read-only zero)
0 or 1
Except M-level can access, other privilege level access will generate illegal instruction exception.
1
0
0
M,S(HS), and U can all access
M, S(HS), and U ????
1
0
1
VS and VU will generate virtual instruction exception
VS and VU will generate virtual instruction exception
1
1
0
M,S(HS), and U level can all access
M,S(HS) can access,U-level will generate illegal instruction exception.
1
1
1
VS and VU????????
VS and VU will generate virtual instruction exception

Regards,
Oscar Jupp


Quetion about SSTC

Oscar Jupp
 

Dear architect,
The stimecmp / vstimecmp” Extension said:
"When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode
raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its
defined behavior as if this extension is not implemented. 
When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp)
when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this
extension is not implemented."


So I made the following table to show the conditions of accessing stimecmp and vstimecmp when menvcfg.STCE, henvcfg.STCE and V take different values.
The blue words in the table are the access conditions I understand. If there are any mistakes, please point it out for me.
The red words in the table are not clear to me, please clarify what is the access conditions of each privilege level.

menvcfg.STCE
henvcfg.STCE
V
Access the CSR with number 0x14D(stimecmp)
Access the CSR with number 0x24D(vstimecmp)
0
0(read-only zero)
0 or 1
Except M-level can access, other privilege level access will generate illegal instruction exception.
1
0
0
M,S(HS), and U can all access
M, S(HS), and U ????
1
0
1
VS and VU will generate virtual instruction exception
VS and VU will generate virtual instruction exception
1
1
0
M,S(HS), and U level can all access
M,S(HS) can access,U-level will generate illegal instruction exception.
1
1
1
VS and VU????????
VS and VU will generate virtual instruction exception

Regards,
Oscar Jupp


Re: Meaning of Implemented in Sstc specification

Oscar Jupp
 

Dear Greg,
Thank you for your reply.
I am sorry that I miss the vital information.

Regards,
Oscar Jupp


---- Replied Message ----
From Greg Favor<gfavor@...>
Date 11/21/2022 12:44
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...> ,
kenney@...<kenney@...>
Subject Re: [RISC-V] [tech-privileged] Meaning of Implemented in Sstc specification
On Sun, Nov 20, 2022 at 4:11 AM jupposcar <jupposcar@...> wrote:
Dear architect,
SSTC spec said: "When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp) when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this extension is not implemented.”
But when STCE in menvcfg is zero and STCE in henvcfg is one, What is the behavior of VSTIP in hip?

The Sstc spec, in the Env Config Support section, says (with my underline):

When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its defined behavior as if this extension is not implemented.


Greg


Re: Meaning of Implemented in Sstc specification

Greg Favor
 

On Sun, Nov 20, 2022 at 4:11 AM jupposcar <jupposcar@...> wrote:
Dear architect,
SSTC spec said: "When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp) when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this extension is not implemented.”
But when STCE in menvcfg is zero and STCE in henvcfg is one, What is the behavior of VSTIP in hip?

The Sstc spec, in the Env Config Support section, says (with my underline):

When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its defined behavior as if this extension is not implemented.


Greg

21 - 40 of 1210