sparc: fix bugs caused by cd7f3a1dbf55
Review Request #3806 - Created Feb. 3, 2017 and submitted
Information | |
---|---|
Brandon Potter | |
gem5 | |
default | |
Reviewers | |
Default | |
ali, gblack, stever |
Changeset 11803:0ab0146d777a --------------------------- 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.
util/regress all
Depends On: |
|
||||||
---|---|---|---|---|---|---|---|
People: |
|
-
src/arch/sparc/faults.cc (Diff revision 1) -
more comments here
-
src/arch/sparc/faults.cc (Diff revision 1) -
Some more comments here would be useful
-
src/arch/sparc/faults.cc (Diff revision 1) -
If you want just a single bit you can use the 2 arg variant of bits(T val, int bit), which will call the 3 arg version with fist == last.
Description: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+107 -6) |
I don't remember much about SPARC address translation, but this looks sufficiently complicated that it's quite believable. Also thanks for the thorough comments; at least if there ever are any issues with or questions about the code, there won't be much doubt about what you intended.
Ship It!
I would argue that this is a prime example why removing SPARC is a good idea.