> On March 16, 2013, 9:48 p.m., Steve Reinhardt wrote: > > src/cpu/kvm/base.cc, line 561 > > <http://reviews.gem5.org/r/1748/diff/1/?file=34422#file34422line561> > > > > This seems a little awkward to me, especially since I don't see where > > it's called from... I'm guessing that's coming up in a later patch. In any > > case, it should use csprintf() rather than ostringstream (we can get rid of > > all the setf() junk then).
OK, this still seems awkward, but after studying it more closely and seeing how it's used, I don't have any better ideas... - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1748/#review4126 ----------------------------------------------------------- On March 9, 2013, 5 p.m., Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1748/ > ----------------------------------------------------------- > > (Updated March 9, 2013, 5 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9620:99f1e74d38f3 > --------------------------- > kvm: Basic support for hardware virtualized CPUs > > 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. > > * dumpState() -- 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. > > > Diffs > ----- > > SConstruct e6347e559e8f > src/cpu/kvm/BaseKvmCPU.py PRE-CREATION > src/cpu/kvm/KvmVM.py PRE-CREATION > src/cpu/kvm/SConscript PRE-CREATION > src/cpu/kvm/base.hh PRE-CREATION > src/cpu/kvm/base.cc PRE-CREATION > src/cpu/kvm/perfevent.hh PRE-CREATION > src/cpu/kvm/perfevent.cc PRE-CREATION > src/cpu/kvm/timer.hh PRE-CREATION > src/cpu/kvm/timer.cc PRE-CREATION > src/cpu/kvm/vm.hh PRE-CREATION > src/cpu/kvm/vm.cc PRE-CREATION > > Diff: http://reviews.gem5.org/r/1748/diff/ > > > Testing > ------- > > > Thanks, > > Ali Saidi > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
