> Not sure what happened with the formatting of this patch, I think there > is an html part getting in the way. I guess line ends were messed up somewhere on my side. Will try to figure out the root cause.
> > + qemu_plugin_vcpu_read_phys_mem(vcpuIndex, vaddr, memContent, > > size); > > So the problem with this approach is the memory value you read here may not be > the same as the value that was read by the instruction. This could > because of a few reasons: > > - an mmio write changes underlying memory layout > - another thread changes memory after the access > > I think a better way to get this information would be to register a new > type of call-back which can duplicate the value in the store/load and > pass it directly to the callback. It might even be worth just fixing up > the existing callback and breaking compatibility rather than having two > callback types? > > We didn't do this originally as we were being cautious about any > attempts to use plugins to workaround the GPL for doing HW emulation - > however I don't think adding the memory values to the callbacks greatly > increases that risk. > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro Do you mean concurrent access to the same memory block by multiple threads? 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). 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?
