From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzrAx-0004Vq-PK for qemu-devel@nongnu.org; Thu, 18 Jul 2013 12:35:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzrAw-00065v-Ig for qemu-devel@nongnu.org; Thu, 18 Jul 2013 12:35:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzrAw-00065i-9b for qemu-devel@nongnu.org; Thu, 18 Jul 2013 12:35:30 -0400 Message-ID: <51E81943.3000705@redhat.com> Date: Thu, 18 Jul 2013 18:35:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374159757-16383-1-git-send-email-fred.konrad@greensocs.com> <51E80B3B.6050604@redhat.com> <51E81857.1050008@greensocs.com> In-Reply-To: <51E81857.1050008@greensocs.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frederic Konrad Cc: Peter Maydell , mark.burton@greensocs.com, qemu-devel@nongnu.org, Orit Wasserman 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, 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