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
