MSTATUS_TVM bit and MSTATUS_SATP in processor_t::set_csr(...)

[MDBrothers]

Shouldn't the MSTATUS_TVM bit value be used to determine if an illegal instruction exception should be raised when attempting to write to the CSR_SATP while executing in S mode? [RISC-V ISA, Volume 2, 3.1.6.4].

riscv/processor.cc:

566     case CSR_SATP: { 
567       mmu->flush_tlb(); 
568       if (max_xlen == 32) 
569         state.satp = val & (SATP32_PPN | SATP32_MODE); 
570       if (max_xlen == 64 && (get_field(val, SATP64_MODE) == SATP_MODE_OFF || 
571                              get_field(val, SATP64_MODE) == SATP_MODE_SV39 || 
572                              get_field(val, SATP64_MODE) == SATP_MODE_SV48)) 
573         state.satp = val & (SATP64_PPN | SATP64_MODE); 
574       break; 
575     } 

The other cases, reading the CSR_SATP in get_csr(…) and the SFENCE.VMA instruction, appear to be correct.

[aswaterman]

You are right, but the way the code is written, that's already happening. The discipline is that the CSR-access instructions always call get_csr before possibly calling set_csr, so there's no need to duplicate the access-checking logic between the two.

[MDBrothers]

Thank you for the clarification. It's good not to be redundant.

On Fri, Aug 23, 2019, 7:13 PM Andrew Waterman notifications@github.com wrote:

You are right, but the way the code is written, that's already happening. The discipline is that the CSR-access instructions always call get_csr before possibly calling set_csr, so there's no need to duplicate the access-checking logic between the two.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-sim/issues/322?email_source=notifications&email_token=ABIH5GIC4DGVSHYV6WEU2O3QGB4LNA5CNFSM4IPER5Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BTF5I#issuecomment-524497653, or mute the thread https://github.com/notifications/unsubscribe-auth/ABIH5GJF36QDDEYVE2R6K43QGB4LNANCNFSM4IPER5YQ .