On Mon, Jan 30, 2012 at 11:18 AM, Stefan Neumann < [email protected]> wrote:
> Hi, > > I've started using MARSSx86 and have some issues with the simulation. > I am aware of the fact that the simulation itself isn't deterministic, but > I do not really understand the mechanism to switch from emulation to > simulation mode an vice versa. > > For my simulations I've compiled the SPEC CPU2006 benchmarks using > ptlcalls. (ptlcall_switch_to_sim and ptlcall_switch_to_native [using the > -stop command]). To shorten the simulation time I've inserted the calls > after the initialization phase of each benchmark and jump back to emulation > after the calculation. > All executables are statically linked. > > To run the the simulation I am using the create_checkpoints/run_bench > scripts. > Checkpoints are created using: > 'cd spec2006bins_static_ptlcall/Xalan/ > ~/create_checkpoint Xalan; ./Xalan -v test.xml xalanc.xsl; echo $?; > ~/stop_sim; shutdown -P now; > Simconfig: > -logfile results5/bwaves.log > -logfilesize 589934592 > -loglevel 999 > -stats results5/bwaves.yml > -machine single_core > Executed command: > qemu-system-x86_64 -m 4G -serial pty -nographic -drive > cache=unsafe,file=spec2006_ptlcalls.qcow2 -simconfig /tmp/Xalan.simconfig > -loadvm Xalan -snapshot > > Xalan.out content: > ptlsim_ptlcall_init: mapped PTLcall MMIO page at phys 0x8fffff000, virt > 0x2ab8e24cc000 [this is the switch_to_sim call] > > What I do not understand is that although I make the ptlcalls during the > execution of the benchmark, the simulation always starts at a different > instruction. I would expect is that after the the MMIO access the emulator > would switch to simulation mode immediately to execute the subsequent > instruction. > > [Example: Xalan 2 different runs] > > Completed 0 cycles, 0 commits: 0 > Hz, 0 insns/sec: rip 0000000000690ee0 > vs. > Completed 0 cycles, 0 commits: 0 > Hz, 0 insns/sec: rip ffffffff81013092 > > Furthermore I also happens (quite often) that after the switch to > simulation, the simulation does not execute the benchmark at all, but > instead seems to stay in some kind of endless loop in kernel space. > > We have recently pushed some fixes on feature branch that is being tested. Can you pull changes from 'features' branch from github? The commit id that tries to solve this issue is : 8e7ca4ba7eb4041c154f4423ab46ebb7b2dfb7ea - Avadh > Does anybody know what is going on there, or can give me a hint on how the > whole MMIO switching mechanism works? > > Out of 81 benchmark runs, 34 got stuck in this kernel loop. (not the idle > loop) > > Thanks and greetings from Germany. > Stefan > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
