Re: Qemu plugin vs. valgrind

[Alex Bennée]

Marc Hacin <address@hidden> writes:

> Le 31/03/2020 à 16:38, Alex Bennée a écrit :
>> Marc Hacin <address@hidden> writes:
<snip>
>> 
>>> On my tests, mono-core, it seems that the load/store callback is
>>> called just after the call of the instruction-before callback which is
>>> the source of the load/store. I didn't see any intermix between memory
>>> and instruction callback, as it is the case on the real guest core.
>> Why would there be? All memory operations will be the result of an
>> instruction being executed.
>
> On the processor core I use, executing :
>       ldwz ra,(rb)            /* insA */
>       ldwz rc,(rd)            /* insB */
> doesn't tell if ra is filled before rc. For exemple if rb points to
> slow PCI space, ra could be filled thousands of processor cycles after
> the insA  load request. Enough to run hundred's of instructions like
> insB as long as ra is not referenced.
> In QEMU, it seems the callback are called pretty synchronously with
> guest instruction flow (because of the many host instructions put
> around I guess, and depending of host architecture).
> So perhaps one can expect that the mem callback of a load instruction
> is always called before any other cb (in my taint analysis, it doesn't 
> matter).

You can - the emulation is all in-order. The only real effect of
accessing some sort of HW device is the real wall-clock time of the
instruction will be longer (as QEMU has more to do).

For multiple threads of execution we do honour the barrier semantics of
the various architectures so properly written code using locks will work
as expected.

-- 
Alex Bennée