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, <fred.kon...@greensocs.com> wrote: >>>> As I said in the last email, we have issues with determinism with >>>> icount. >>>> 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 > tests. >> 2) never does any network operation nor any asynchronous disk I/O >> operation >> >> 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 > device. > > 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. Paolo
