[Top][All Lists]

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

Re: [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount.

From: Frederic Konrad
Subject: Re: [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount.
Date: Fri, 19 Jul 2013 17:26:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

On 18/07/2013 18:35, Paolo Bonzini wrote:
Il 18/07/2013 18:31, Frederic Konrad ha scritto:
On 18/07/2013 17:35, Paolo Bonzini wrote:
Il 18/07/2013 17:06, Peter Maydell ha scritto:
On 18 July 2013 16:02,  <address@hidden> wrote:
As I said in the last email, we have issues with determinism with
We are wondering if determinism is really ensured with icount?
My opinion is that it *should* be deterministic but it would
be unsurprising if the determinism had got broken along the way.
First of all, it can only be deterministic if the guest satisfies (at
least) all the following condition:

1) only uses timer that QEMU bases on vm_clock (which means that you
should use "-rtc clock=vm"---sorry Fred, didn't think about this in the
previous answer);
Oops sorry, I didn't mentioned that, but we used rtc clock=vm for our
2) never does any network operation nor any asynchronous disk I/O

3) never halts the VCPU waiting for an interrupt

Point 1 is obvious.

To explain points 2, let's consider what happens if a block device uses
synchronous vs. asynchronous I/O.

With synchronous I/O, each block device operation will complete
immediately.  All clocks are stalled during the operation.

With asynchronous I/O, each block device operation will be done while
the CPU is running.  If the CPU is polling a completion flag, the number
of instructions executed (thus icount) depends on how long it takes to
do I/O.
So I suppose this can happen even if there are any network card or block

We probably need to disable it until we finally save and replay IO, to
get this thing working.
Are you aware of the work that was done on fault tolerance (Kemari)?
Orit is working on resurrecting it.


No, but I will take a look that can be really usefull for IO.


reply via email to

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