-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3806/#review9433
-----------------------------------------------------------

Ship it!


I would argue that this is a prime example why removing SPARC is a good idea.

- Andreas Hansson


On Feb. 10, 2017, 8:31 p.m., Brandon Potter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3806/
> -----------------------------------------------------------
> 
> (Updated Feb. 10, 2017, 8:31 p.m.)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, and Steve Reinhardt.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   src/arch/sparc/process.cc cd7f3a1dbf55bfa03b436c8cde51ebda515fbdbc 
>   src/arch/sparc/faults.cc cd7f3a1dbf55bfa03b436c8cde51ebda515fbdbc 
> 
> Diff: http://reviews.gem5.org/r/3806/diff/
> 
> 
> Testing
> -------
> 
> util/regress all
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to