Hi all,
I've just pushed a couple of patches that add full system support to
RISC-V and a also few bug fixes. We cannot run Linux yet (I didn't try),
but we can run software that uses virtual memory :)
The status is that all tests of the RISC-V test suite work in the p, ps
and v environment, except for:
- fence.i tests: these tests fail, because we currently don't invalidate
the icache for that instruction, so that self-modifying code doesn't
work.
- floating point tests: there are still several issues with floating
point instructions that I didn't look into.
- some tests fail with the MinorCPU, but I think that is expected.
- in the rv64mi-illegal test, I disabled the waiting for a timer IRQ,
because we don't have a timer.
Note also that none of these worked before my patches.
I have a couple of questions and comments to the patches:
- The commit "tests: call sys.exit() on failure in Simulation::run."
exits the simulation with the exit code given by exit_event. This
is necessary to report success/failure for the RISC-V tests. I am
not sure if it has side effects on other tests or so.
- The RISC-V unprivileged ISA manual states:
CSR access are performed in program order with respect to those
instructions whose execution behavior is affected by the state of the
accessed CSR. In particular, a CSR access is performed after the
execution of any prior instructions in program order whose behavior
modifies or is modified by the CSR state and before the execution of any
subsequent instructions in program order whose behavior modifies or is
modified by the CSR state.
My current patch ("arch-riscv: make accesses to CSRs SerializeAfter.")
makes them simply SerializeAfter, which works in all tests. However,
shouldn't a CSR access also be executed *after* all instructions
before? Because what if the instruction before a CSR write relies on
the CSR state before the change and the O3 CPU executes these
instructions in the opposite order?
I noticed that there is IsSerializeBefore as well, but apparently, an
instruction cannot really be both, because IsSerializeBefore is
preferred over the other and thus effectively disables
IsSerializeAfter (see rename_impl.hh, line 721ff).
Did I misunderstand that or is there indeed something not entirely
correct?
- Since I based the implementation of the TLB and page table walker on
x86, I noticed that accessed/dirty flag setting seems to be broken on
x86. At first, the dirty flag is not set at all, as far as I can see.
And second, the accessed flag is not set for leaf PTEs, because if
doEndWalk is true, doWrite (to update the PTE) is not considered.
- Another problem I ran into with RISC-V is a page fault caused by an
atomic instruction. As it seems, the instruction is stuck in the
IEW stage and thus can never be commited. I did a bit of trial and
error and found that the attached workaround solves the problem.
However, this is of course a stupid fix. Does anybody know how to fix
it properly?
Best regards,
Nils
---
diff --git a/src/cpu/o3/iew_impl.hh b/src/cpu/o3/iew_impl.hh
index 99dfd19c3..369d3ee71 100644
--- a/src/cpu/o3/iew_impl.hh
+++ b/src/cpu/o3/iew_impl.hh
@@ -1278,6 +1278,18 @@ DefaultIEW<Impl>::executeInsts()
instQueue.deferMemInst(inst);
continue;
}
+
+ // If the AMO had a fault then it may not have a mem req
+ if (fault != NoFault &&
+ strcmp(fault->name(), "panic fault") != 0) {
+ // If the instruction faulted, then we need to send it
+ // along to commit without the instruction completing. Send
+ // this instruction to commit, also make sure iew stage
+ // realizes there is activity.
+ inst->setExecuted();
+ instToCommit(inst);
+ activityThisCycle();
+ }
} else if (inst->isLoad()) {
// Loads will mark themselves as executed, and their writeback
// event adds the instruction to the queue to commit
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
