Sure: https://gem5.atlassian.net/browse/GEM5-367
Best regards, Nils On 2/24/20 5:51 PM, Jason Lowe-Power wrote: > 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 > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
