Searched hist:11850 (Results 1 - 4 of 4) sorted by relevance
| /gem5/src/arch/sparc/ | ||
| H A D | faults.cc | 11850:36119fa7874d Fri Feb 17 00:01:00 EST 2017 Brandon Potter <brandon.potter@amd.com> 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. |
| H A D | process.cc | 11850:36119fa7874d Fri Feb 17 00:01:00 EST 2017 Brandon Potter <brandon.potter@amd.com> 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. |
| /gem5/configs/example/ | ||
| H A D | fs.py | 13803:32c104f40e57 Wed Jul 25 18:07:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> configs: Remove default kernel value from system creation Kernel was being set using a placeholder and then assigned the correct value. This would generate the following error if the placeholder file did not exist: 'IOError: Can't find file <placeholder> on path' This patch follows the same directions of commit 12eca7ac04ae1ba559bf322b5c625513929d369d and removes the default values, forcing the user to properly configure the kernel. Change-Id: I0eb45d12eda6b6efe9a3fe118996b640844a7b34 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/11850 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/configs/common/ | ||
| H A D | FSConfig.py | 13803:32c104f40e57 Wed Jul 25 18:07:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> configs: Remove default kernel value from system creation Kernel was being set using a placeholder and then assigned the correct value. This would generate the following error if the placeholder file did not exist: 'IOError: Can't find file <placeholder> on path' This patch follows the same directions of commit 12eca7ac04ae1ba559bf322b5c625513929d369d and removes the default values, forcing the user to properly configure the kernel. Change-Id: I0eb45d12eda6b6efe9a3fe118996b640844a7b34 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/11850 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
Completed in 107 milliseconds