On Thu, Jan 6, 2011 at 12:41 PM, Teng-Feng Yang <[email protected]>wrote:
> 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? > > You can do following when you want to switch to QEMU mode: - Call 'ptl_machine_reconfigure' with "-stop" argument to switch to emulation mode. This will set 'in_simulation' to 0. - return COMMIT_RESULT_STOP or COMMIT_RESULT_INTERRUPT to exit from main loop in 'run' function. This should work but I haven't tested this method. - Avadh > 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
