[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] QEMU: DBT vs. Interpretation

From: Javier Picorel
Subject: Re: [Qemu-discuss] QEMU: DBT vs. Interpretation
Date: Wed, 28 Jan 2015 11:38:37 +0100

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!


> On 28 Jan 2015, at 11:18, Peter Maydell <address@hidden> wrote:
> On 28 January 2015 at 02:51, Dale R. Worley <address@hidden> wrote:
>> Javier Picorel <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]