Hi Nils, This is awesome! Getting closer to full system support for RISC-V is really cool! I'm excited to dig into the code.
Could you create an Epic about this on the Jira instance: https://gem5.atlassian.net/projects/GEM5/issues. This will make it easier to track the progress, etc. Cheers, Jason On Mon, Feb 24, 2020 at 4:57 AM Nils Asmussen <n...@os.inf.tu-dresden.de> wrote: > 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 _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
