Yes, your assumption is right. Every time we execute
the same binary and settings (w/o I/O), we get the same
instruction trace. The question is whether DBT introduces
any source of indeterminism (e.g., arbitrary reordering of
instructions in the TB or something that does not violate
correctness but it’s not exactly the same). We checked the
code and it seems that the TCG generates the same code
every time, but we would like some confirmation. Thanks!
Regards,
Javier
On 28 Jan 2015, at 11:18, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 January 2015 at 02:51, Dale R. Worley wor...@alum.mit.edu wrote:
Javier Picorel javier.pico...@epfl.ch writes:
We are trying to make QEMU deterministic for
architectural simulation. In the absence of I/O,
let's say only user code or exceptions, is there
any source of indeterminism (e.g., non deterministic
compiler optimizations, TB indeterminism) of
QEMU's DBT versus a canonical interpreter? Thanks!
I'm not sure exactly what information you're trying to obtain. Given
that most CPU architectures have multiple implementations, and many of
those have complex internal operations, it's difficult to make an
emulator deterministic in any way other than its behavior conforms to
the architecture specification.
I had assumed the meaning here was deterministic in the sense
of every time you run QEMU with the same binary and settings
you get exactly the same execution run. With the default
switches we don't provide that (we give 'best performance'
instead). -icount is I think supposed to be deterministic but
probably buggy. Determinism is a requirement for the checkpoint/
reverse execution work so the people doing that are probably
best placed to say what the current status is.
-- PMM
