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

[Paolo Bonzini <pbonzini@redhat.com>]

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.konrad@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