RE: [PATCH v2] TCG plugin API extension to read guest memory content by an address

[Mikhail Tyutin]

> > Do you mean concurrent access to the same memory block by multiple
> > threads?
> 
> Yes - although we also see MMU changes updating a mapping for a given
> vaddr -> phys address.
> 
> >
> > I think , for guest threads/cores if we observe mismatch of memory content 
> > read by a plugin and instruction
> > itself, then it should clearly indicate that guest software has true data 
> > race problem sitting somewhere
> > in its code. Otherwise other threads would wait on a synchronization object 
> > to let current thread
> > perform both memory operations (plugin callback + instruction).
> 
> Other threads don't pause at all (unless you do something in the plugin
> to force that)

By correct multi-threaded code I mean that two concurrent accesses should
be synchronized by the application itself to ensure it correctness. For example
two thread access the same memory using a lock:

T1:
Lock         
  read mem
Unlock

T2:
Lock
  write mem
Unlock

If a plugin inserts memory callback at read/write mem instruction, it will be
implicitly synchronized with another thread.

On the other hand, if application misses the lock, it has data race regardless
of inserted callbacks. So, the plugin will get undefined content anyway.
T1                  T2
read mem    write mem

 
> > On the other hand, concurrent access
> > using atomic operation will indeed cause either plugin or instruction to 
> > read invalid memory content.
> >
> > Isn’t it the same problem as we face in case of GDB attached to running 
> > Qemu instance (gdbserver) and
> > asking it to read some memory? How is it solved there?
> 
> Yes and it's not solved except usually most interactions with the guest
> during debugging are while the system is paused.
> 
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro