All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Konrad <fred.konrad@greensocs.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	mark.burton@greensocs.com, qemu-devel@nongnu.org,
	Orit Wasserman <owasserm@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount.
Date: Fri, 19 Jul 2013 17:26:30 +0200	[thread overview]
Message-ID: <51E95AA6.3020606@greensocs.com> (raw)
In-Reply-To: <51E81943.3000705@redhat.com>

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,  <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

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

Thanks,
Fred

  reply	other threads:[~2013-07-19 15:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18 15:02 [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount fred.konrad
2013-07-18 15:02 ` [Qemu-devel] [RFC 1/3] icount: base rt_clock on icount fred.konrad
2013-07-18 15:36   ` Paolo Bonzini
2013-07-18 16:23     ` Frederic Konrad
2013-07-18 16:26       ` Paolo Bonzini
2013-07-18 15:02 ` [Qemu-devel] [RFC 2/3] icount: sync vm_clock on the next event fred.konrad
2013-07-18 15:02 ` [Qemu-devel] [RFC 3/3] icount: create a new icount based timer fred.konrad
2013-07-18 15:08   ` Peter Maydell
2013-07-18 15:06 ` [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount Peter Maydell
2013-07-18 15:09   ` Frederic Konrad
2013-07-18 15:12     ` Peter Maydell
2013-07-18 15:35   ` Paolo Bonzini
2013-07-18 16:31     ` Frederic Konrad
2013-07-18 16:35       ` Paolo Bonzini
2013-07-19 15:26         ` Frederic Konrad [this message]
2013-07-29 15:27     ` Frederic Konrad
2013-07-29 16:42       ` Paolo Bonzini
2013-07-30  7:06         ` Frederic Konrad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E95AA6.3020606@greensocs.com \
    --to=fred.konrad@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.