eb4a5c15ce
When the new thread context ctc is created, it should have a copy of all the state in the original tc, including the original PC. This code used to specially handle the KVM case by explicitly making this new context return from the system call immediately by jumping right to RCX which (assuming a particular instruction was used) is where user mode should resume. The first problem with this approach as far as I can tell is that the CPU will still be in CPL0, ie supervisor mode, and will not have been forced back into CPL3, ie user mode. This may not have any immediately visible effect, but may down the line. Second, this seems unnecessary. The non-special case code will advance the PC beyond the instruction which triggered the system call. Then once the new thread starts executing again, it will execute sysret and return to rcx naturally, just like the original thread will. The only observed difference is that when executing a gem5 instruction, the IP is set to the currently executing instruction, and so to avoid the new context from re-executing the system call, the PC needs to be advanced. When calling in from KVM, the instruction has already been "completed", and so the IP should *not* be advanced. Also note that when reading the PCState object in KVM, it doesn't figure out where the next instruction is and so NPC is just one ExtMachInst sized blob later on. Advancing the PC will just move to an address 8 bytes later, which is very unlikely to be what you want. Jira Issue: https://gem5.atlassian.net/browse/GEM5-187 Change-Id: I0d97f66e64ce39b13d6700dcf3d7da88d6fe0048 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23199 Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.