d4e9a34590
The memory-mapped timer emulated by gem5 is driven by the underlying gem5 tick, which means that we must align the tick with the host time to make the timer interrupt fire at a nearly native rate. In each KVM execution round, the number of ticks incremented is directly calculated from the number of instructions executed. However, when a guest CPU switches to idle state, KVM seems to stay in kernel- space until the POSIX timer set up in user-space raises an expiration signal, instead of trapping to user-space immediately; and somehow the instruction count is just too low to match the elapsed host time. This makes the gem5 tick increment very slowly when the guest is idle and drastically slow down workloads being sensitive to the guest time which is driven by timer interrupt. Before switching to KVM to execute the guest code, gem5 programs the POSIX timer to expire according to the remaining ticks before the next event in the event queue. Based on this, we can come up with the following solution: If KVM returns to user-space due to POSIX timer expiration, it must be time to process the next gem5 event, so we just fast-forward the tick (by scheduling the next CPU tick event) to that event directly without calculating from the instruction count. There is one more related issue needed to be solved. The KVM exit reason, KVM_EXIT_INTR, was treated as the case where the KVM execution was disturbed by POSIX timer expiration. However, there exists a case where the exit reason is KVM_EXIT_INTR but the POSIX timer has not expired. Its cause is still unknown, but it can be observed via the "old_value" argument returned by timer_settime() when disarming the POSIX timer. In addition, it seems to happen often when a guest CPU is not in idle state. When this happens, the above tick event scheduling incorrectly treats KVM_EXIT_INTR as POSIX timer expiration and fast- forwards the tick to process the next event too early. This makes the guest feel external events come too fast, and will sometimes cause trouble. One example is the VSYNC interrupt from HDLCD. The guest seems to get stuck in VSYNC handling if the KVM CPU is not given enough time between each VSYNC interrupt to complete a service. (Honestly I did not dig in to see how the guest handled the VSYNC interrupt and how the above situation became trouble. I just observed from the debug trace of GIC & HDLCD & timer, and made this conclusion.) This change also uses a workaround to detect POSIX timer expiration correctly to make the guest work with HDLCD. JIRA: https://gem5.atlassian.net/browse/GEM5-663 Change-Id: I6159238a36fc18c0c881d177a742d8a7745a23ca Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30919 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.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.