Conversation
a0u
left a comment
There was a problem hiding this comment.
A very unlikely race condition could occur where the core takes an exception after the RoCC instruction is issued and privileged code modifies the satp CSR before the walk completes. Not much could be done about this, though, with the RoCC interface being asynchronous and no way to provide a separate copy of satp to the PTW without changing rocket-chip.
| resp_q.io.enq.valid := Mux(in_flight, io.ptw(0).resp.valid, !vm_enabled && in_q.valid) | ||
| resp_q.io.enq.bits.rd := in_q.bits.inst.rd | ||
| resp_q.io.enq.bits.data := Mux(in_flight, | ||
| Mux(io.ptw(0).resp.bits.pf, 0.U, Cat(io.ptw(0).resp.bits.pte.ppn, in_q.bits.rs1(pgIdxBits-1,0))), |
There was a problem hiding this comment.
Is the intent here to determine whether a mapping exists or whether an access would succeed?
As far as I know, io.ptw(0).resp.bits.pf only indicates if the PTE is invalid or the reserved bits are non-zero, not necessarily if the permissions are adequate. Of course, this suffices for the first use case but not the latter.
Access exceptions (ae_ptw and ae_final) should probably also mask the result.
This is a RoCC "accelerator" that makes it fast and easy for user programs to determine page mappings. It supports a single instruction that performs a PTW using the PTW on the host core.