summaryrefslogtreecommitdiff
path: root/src/arch/riscv
diff options
context:
space:
mode:
authorBrandon Potter <brandon.potter@amd.com>2017-02-17 12:01:51 -0500
committerBrandon Potter <brandon.potter@amd.com>2017-02-17 12:01:51 -0500
commit7b6cf951e2f0fa70d6599f1e1d03f664b674a75e (patch)
tree342f92ef408a0f61a8931ac520f211cd5a55e6da /src/arch/riscv
parent96f8ff57025947a6f2afd28ca4b8b6126a15b09d (diff)
downloadgem5-7b6cf951e2f0fa70d6599f1e1d03f664b674a75e.tar.xz
sparc: fix bugs caused by cd7f3a1dbf55
Turns out that SPARC SE mode relied on M5_pid being "0" in all cases. The entries in the SPARC TLBs are accessed with M5_pid as their context. This is buggy in the sense that it will never work with more than one process or any initialization that doesn't have the M5_pid value passed in as "0". cd7f3a1dbf55 broke the SPARC build because it deletes M5_pid and uses a _pid with a default of "100" instead. This caused the SPARC TLB to never return any valid lookups for any request; the program never moved past the first instruction with SPARC SE in the regression tester. The solution proposed in this changeset is to initialize the address space identification register with the PID value that is passed into the process class as a parameter from Python. This should return the correct responses from the TLB since the insertions and lookups into the page table will be using the same PID. Furthermore, there are corner cases in the code which elevate privileges and revert to using context "0" as the context in the TLB. I believe that these are related to kernel level traps and hypervisor privilege escalations, but I'm not completely sure. I've tried to address the corner cases properly, but it would be beneficial to have someone who is familiar with the SPARC architecture to take a look at this fix.
Diffstat (limited to 'src/arch/riscv')
0 files changed, 0 insertions, 0 deletions