summaryrefslogtreecommitdiff
path: root/src/cpu/kvm
AgeCommit message (Collapse)Author
2013-05-02kvm: Add checkpoint debug printAndreas Sandberg
Add a debug print (when the Checkpoint debug flag is set) on serialize and unserialize. Additionally, dump the KVM state before serializing. The KVM state isn't dumped after unserializing since the state is loaded lazily on the next KVM entry.
2013-05-02kvm: Make MMIO requests uncacheableAndreas Sandberg
Device accesses are normally uncacheable. This change probably doesn't make any difference since we normally disable caching when KVM is active. However, there might be devices that check this, so we'd better enable this flag to be safe.
2013-04-22kvm: Add support for pseudo-ops on ARMAndreas Sandberg
This changeset adds support for m5 pseudo-ops when running in kvm-mode. Unfortunately, we can't trap the normal gem5 co-processor entry in KVM (it doesn't seem to be possible to trap accesses to non-existing co-processors). We therefore use BZJ instructions to cause a trap from virtualized mode into gem5. The BZJ instruction is becomes a normal branch to the gem5 fallback code when running in simulated mode, which means that this patch does not need to change the ARM ISA-specific code. Note: This requires a patched host kernel.
2013-04-22kvm: Add support for state dumping on ARMAndreas Sandberg
2013-04-22kvm: Add basic support for ARMAndreas Sandberg
Architecture specific limitations: * LPAE is currently not supported by gem5. We therefore panic if LPAE is enabled when returning to gem5. * The co-processor based interface to the architected timer is unsupported. We can't support this due to limitations in the KVM API on ARM. * M5 ops are currently not supported. This requires either a kernel hack or a memory mapped device that handles the guest<->m5 interface.
2013-04-22kvm: Add experimental support for a perf-based execution timerAndreas Sandberg
Add support for using the CPU cycle counter instead of a normal POSIX timer to generate timed exits to gem5. This should, in theory, provide better resolution when requesting timer signals. The perf-based timer requires a fairly recent kernel since it requires a working PERF_EVENT_IOC_PERIOD ioctl. This ioctl has existed in the kernel for a long time, but it used to be completely broken due to an inverted match when the kernel copied things from user space. Additionally, the ioctl does not change the sample period correctly on all kernel versions which implement it. It is currently only known to work reliably on kernel version 3.7 and above on ARM.
2013-04-22kvm: Avoid synchronizing the TC on every KVM exitAndreas Sandberg
Reduce the number of KVM->TC synchronizations by overloading the getContext() method and only request an update when the TC is requested as opposed to every time KVM returns to gem5.
2013-04-22kvm: Basic support for hardware virtualized CPUsAndreas Sandberg
This changeset introduces the architecture independent parts required to support KVM-accelerated CPUs. It introduces two new simulation objects: KvmVM -- The KVM VM is a component shared between all CPUs in a shared memory domain. It is typically instantiated as a child of the system object in the simulation hierarchy. It provides access to KVM VM specific interfaces. BaseKvmCPU -- Abstract base class for all KVM-based CPUs. Architecture dependent CPU implementations inherit from this class and implement the following methods: * updateKvmState() -- Update the architecture-dependent KVM state from the gem5 thread context associated with the CPU. * updateThreadContext() -- Update the thread context from the architecture-dependent KVM state. * dump() -- Dump the KVM state using (optional). In order to deliver interrupts to the guest, CPU implementations typically override the tick() method and check for, and deliver, interrupts prior to entering KVM. Hardware-virutalized CPU currently have the following limitations: * SE mode is not supported. * PC events are not supported. * Timing statistics are currently very limited. The current approach simply scales the host cycles with a user-configurable factor. * The simulated system must not contain any caches. * Since cycle counts are approximate, there is no way to request an exact number of cycles (or instructions) to be executed by the CPU. * Hardware virtualized CPUs and gem5 CPUs must not execute at the same time in the same simulator instance. * Only single-CPU systems can be simulated. * Remote GDB connections to the guest system are not supported. Additionally, m5ops requires an architecture specific interface and might not be supported.