-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1567/#review3741
-----------------------------------------------------------

Ship it!


Ship It!

- Anthony Gutierrez


On Dec. 6, 2012, 12:39 p.m., Ali Saidi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1567/
> -----------------------------------------------------------
> 
> (Updated Dec. 6, 2012, 12:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9416:bd70be5d8496
> ---------------------------
> cpu: Make sure that a drained atomic CPU isn't executing ucode
> 
> Currently, the atomic CPU can be in the middle of a microcode sequence
> when it is drained. This leads to two problems:
> 
>  * When switching to a hardware virtualized CPU, we obviously can't
>    execute gem5 microcode.
> 
>  * Since curMacroStaticInst is populated when executing microcode,
>    repeated switching between CPUs executing microcode leads to
>    incorrect execution.
> 
> After applying this patch, the CPU will be on a proper instruction
> boundary, which means that it is safe to switch to any CPU model
> (including hardware virtualized ones). This changeset fixes a bug
> where the multiple switches to the same atomic CPU sometimes corrupts
> the target state because of dangling pointers to the currently
> executing microinstruction.
> 
> Note: This changeset moves tick event descheduling from switchOut() to
> drain(), which makes timing consistent between just draining a system
> and draining /and/ switching between two atomic CPUs. This makes
> debugging quite a lot easier (execution traces get the same timing),
> but the latency of the last instruction before a drain will not be
> accounted for correctly (it will always be 1 cycle).
> 
> Note 2: This changeset removes so_state variable, the locked variable,
> and the tickEvent from checkpoints since none of them contain state
> that needs to be preserved across checkpoints. The so_state is made
> redundant because we don't use the drain state variable anymore, the
> lock variable should never be set when the system is drained, and the
> tick event isn't scheduled.
> 
> 
> Diffs
> -----
> 
>   src/cpu/simple/atomic.hh 844f9e724343 
>   src/cpu/simple/atomic.cc 844f9e724343 
> 
> Diff: http://reviews.gem5.org/r/1567/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ali Saidi
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to