From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0Cnx-0002cu-At for qemu-devel@nongnu.org; Fri, 19 Jul 2013 11:41:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0Cnt-0008FY-89 for qemu-devel@nongnu.org; Fri, 19 Jul 2013 11:41:13 -0400 Received: from [2001:41d0:8:2b42::1] (port=51545 helo=ns232118.ovh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0CZn-0002nE-Eo for qemu-devel@nongnu.org; Fri, 19 Jul 2013 11:26:35 -0400 Message-ID: <51E95AA6.3020606@greensocs.com> Date: Fri, 19 Jul 2013 17:26:30 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <1374159757-16383-1-git-send-email-fred.konrad@greensocs.com> <51E80B3B.6050604@redhat.com> <51E81857.1050008@greensocs.com> <51E81943.3000705@redhat.com> In-Reply-To: <51E81943.3000705@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Paolo Bonzini Cc: Peter Maydell , mark.burton@greensocs.com, qemu-devel@nongnu.org, Orit Wasserman 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, 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