Re: [Gems-users] Using the timing model to change store values when using Lazy VM

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

Fuad,

You are right in that we do not exactly follow the guidelines specified 
in the documentation. As I recall,
we did it the 'recommended' way at first but there was a possibility of 
race conditions. So we ignored the
guidelines and since our hack works, we stuck to it.

We initially remembered the old value in a buffer and allowed Simics to 
write new value to physical memory.
The old value was subsequently restored on a snoop-device callback 
(retiredMemRef). However,
this meant that there was a small window of time during which the new 
value was visible to other processors
(I dont remember if we actually saw this during execution).

To avoid this race, we had to prevent Simics from storing the new value 
into physical memory. So we change
the contents of the memory request object to the old value just before 
we return 0 to Simics. This seemed
to store the old values into physical memory (even though the API call 
was made from the timing model).
Now if you return a non-zero value, Simics will re-issue the memory 
request with a new object which I guess
contains the new value. So you will have to clobber it with the old 
value again...
Jayaram

Fuad Tabba wrote:
> Hi,
>
> I've noticed that when using lazy vm (ATMTP), in 
> TransactionSimicsProcessor::redirectStoreToWriteBuffer  you use 
> SIM_c_set_mem_op_value_buf  in order to change the store value in the 
> memory transaction back to the original one found in main memory, 
> while adding the new value to the write buffer.
> The Simics reference manual states (under SIM_c_set_mem_op_value_buf) 
> that:-
> "These functions cannot be called from a timing-model since the real 
> operation will overwrite the value set. They should instead be used 
> from a snoop-device."
> Moreover, in the Simics programming manual it also says that:-
> "If the value of a memory store has been changed in the timing model, 
> it should be reset in the snoop device."
> Which seems to be a contradiction, where else would you store the 
> value? It seems to me that you sort of ignore both statements and it 
> seems to work for you guys. I've tried to understand this code better, 
> and I've noticed that by actually changing the stall time to anything 
> other than 0, then the value is indeed lost.
>
> My question is this, there's a clear contradiction in the Simics 
> documentation, yet you have obviously managed to get this working. Can 
> you enlighten me on how this actually behaves in regards to GEMS/Ruby 
> with Lazy VM? :)
> Thanks.
>
> Cheers,
> /fuad
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>