Let me see if I understand what you wrote:

In the emulation mode, PTLsim and the cache model are off and QEMU
runs by itself.

In the simulation mode, QEMU is off and PTLsim and the cache model are
on.  However, the data values of processor loads and stores are,
respectively, read from and written to the memory directly.  The cache
model, together with PTLsim, control the timing of the propagation and
use of those data values in the modeled guest microarchiture, but does
not actually track those values.  So when Switching from simulation
mode to emulation mode, Marss can simply throw away the states in the
cache model, because the store values have already been written to
memory and thus available to QEMU when it comes back.

But there are still two things unclear to me:

* At precisely which point in time is a store value written to memory?
 When it passes from the processor model to the cache model, or when
the processor obtains exclusive ownership of the store's cache line,
or at some other point?

* In the simulation mode, how does Marss enforce the atomicity of
atomic read-modify-write instructions?

Thanks!
- Ching Tsun

On Friday, July 1, 2011, avadh patel <[email protected]> wrote:
>
> On Thu, Jun 30, 2011 at 4:24 PM, Ching-Tsun Chou <[email protected]> 
> wrote:
>
>
> When Marss is in the emulation mode (i.e., when it is running QEMU only and 
> not PTLsim), do the guest's memory operations still go through the cache 
> hierarchy model?  Or are they directly satisfied by the guest's memory?
>
>
>
> No, none of the memory access go through simulated cache model.
>
> If the answer is the former, then QEMU needs to be modified to use the cache 
> hierarchy model.  Could you point out where the code changes in QEMU are?
> There are few people working on it but I am not sure about their progress. 
> Its little complicated because QEMU uses JIT which convert VM instructions 
> into simple opcodes and then compile them into binary for optimized 
> performance. This is called Tiny Code Generator (TCG) which has also modified 
> the old method of memory access that was using 'softmmu_template.h' file. 
> You'll have to look up TCG code to find out how all memory access in 
> emulation mode is done.
>
>  If the answer is the latter, does it mean that the switch from simulation 
> mode to emulation mode would involve some sort of draining of the cache 
> hierarchy to memory to ensure that all modified cache lines are written back 
> to memory?  Could you point out where the code for doing that is?
>
>
>
> In simulation mode, all the caches dont store any data. They only hold the 
> cache line addresses and cache line states. On a memory write, if line is in 
> valid state then it's data is directly written to RAM and we just simulate 
> the delay in caches.
>
>
> - Avadh Thanks!- Ching Tsun
>
>

_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel

Reply via email to