Hi~ I have been working on switching between PTLsim and QEMU these days, and I have noticed that "stop_at_next_eom" also indicates that after next x86 instruction commit this thread should be stopped. If the commit stage return COMMIT_RESULT_STOP, the machine->stopped[thread->ctx.core_idx] would be set to 1. As far as I know, PTLsim could run multiple thread contexts on a single core. I am wondering why machine->stopped[thread->ctx.core_idx] is set when only one of threads running on it stop?
Since I want to switch from PTLsim to QEMU at any specific sim_cycle, I plan to do the following modification 1. If sim_cycle has reached a specific threshold, set "stop_at_next_eom" of all threads in all cores to stop them. 2. After all threads have stopped, switch all context to QEMU and set in_simulation to 0 by return 0 from ptl_simulate. Do I miss anything? Any help would be grateful!! Teng-Feng 2010/12/28 avadh patel <[email protected]> > On Mon, Dec 27, 2010 at 4:10 AM, Teng-Feng Yang <[email protected]>wrote: > >> Hi~ >> >> What is the purpose of the checker called by the commit stage in >> ooopipe.cpp? >> It seems that it switches back to the QEMU and functionally simulate the >> checker_context, but I don't understand what to check via this checker. >> >> Checker is a CPU Context that is run in parallel to simulated CPU Context > and after every instruction commit they both are compared for simulator's > correctness. This checker context is run in QEMU and it runs only in User > mode simulation. I use this checker to find bugs in simulator CPU model > that breaks the simulation correctness and crash the simulator. Though > checker doesn't run all the time so it not useful to find bugs in Kernel > mode. > > This happens only when '-enable-checker' option is set. > > >> Here is another question. >> It seems to me that during the simulation process of marss, it is ok to >> switch between functional simulation (QEMU) and detail simulation (PTLsim) >> only if we manage to provide the right context and call setup_xxx_switch >> between them. >> Is this correct? >> >> Yes. One more thing to add here, you have to make sure that simulator > model is not in partial commit mode. For example, if its simulating x86 > instruction that has 4 uops and in cycle-1 2 uops are committed then you > can't change to QEMU mode untill rest of the uops in that instruction are > committed. If you look at the code you might find a variable > 'handle_interrupt_at_next_eom' which indicates that after next x86 > instruction commit there is an interrupt pending so don't start committing > other instruction because we might switch to QEMU mode. > > - Avadh > >> Any help would be grateful! >> >> Thanks again for the great simulator >> >> Teng-Feng >> >> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> > -- Teng Feng Yang Research Assistant of Director. P.C. Yew Parallel Processing Laboratory Institute of Information Science Academia Sinica, Taiwan Tel: 886-2-27883799#1676 E-mail:[email protected] <e-mail%[email protected]>
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
