From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42368)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V2dct-00049l-JY
	for qemu-devel@nongnu.org; Fri, 26 Jul 2013 04:43:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V2dcr-0004I3-6I
	for qemu-devel@nongnu.org; Fri, 26 Jul 2013 04:43:51 -0400
Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:44034)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V2dcr-0004Hk-0D
	for qemu-devel@nongnu.org; Fri, 26 Jul 2013 04:43:49 -0400
Received: by mail-ea0-f181.google.com with SMTP id d10so276548eaj.26
	for <qemu-devel@nongnu.org>; Fri, 26 Jul 2013 01:43:48 -0700 (PDT)
Date: Fri, 26 Jul 2013 10:43:45 +0200
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130726084345.GE31438@stefanha-thinkpad.redhat.com>
References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com>
	<20130725120530.GJ21033@stefanha-thinkpad.redhat.com>
	<C471CD9FB0C93A3C362BD247@nimrod.local>
	<51F11AFB.9040008@siemens.com>
	<1A5D30F9703985AD026648F0@nimrod.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1A5D30F9703985AD026648F0@nimrod.local>
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Bligh <alex@alex.org.uk>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>, Liu Ping Fan <qemulist@gmail.com>, qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>, Paolo Bonzini <pbonzini@redhat.com>

On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
> 
> 
> --On 25 July 2013 14:32:59 +0200 Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
> >>I would happily at a QEMUClock of each type to AioContext. They are after
> >>all pretty lightweight.
> >
> >What's the point of adding tones of QEMUClock instances? Considering
> >proper abstraction, how are they different for each AioContext? Will
> >they run against different clock sources, start/stop at different times?
> >If the answer is "they have different timer list", then fix this
> >incorrect abstraction.
> 
> Even if I fix the abstraction, there is a question of whether it is
> necessary to have more than one timer list per AioContext, because
> the timer list is fundamentally per clock-source. I am currently
> just using QEMU_CLOCK_REALTIME as that's what the block drivers normally
> want. Will block drivers ever want timers from a different clock source?

block.c and block/qed.c use vm_clock because block drivers should not do
guest I/O while the vm is stopped.  This is especially true during live
migration where it's important to hand off the image file from the
source host to the destination host with good cache consistency.  The
source host is not allowed to modify the image file anymore once the
destination host has resumed the guest.

Block jobs use rt_clock because they aren't considered guest I/O.

Stefan