From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3ky4-0007TA-MK for qemu-devel@nongnu.org; Mon, 29 Jul 2013 06:46:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3kxz-0007od-St for qemu-devel@nongnu.org; Mon, 29 Jul 2013 06:46:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3kxz-0007oY-Ki for qemu-devel@nongnu.org; Mon, 29 Jul 2013 06:46:15 -0400 Message-ID: <51F647D8.5060600@redhat.com> Date: Mon, 29 Jul 2013 12:45:44 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com> <20130725120530.GJ21033@stefanha-thinkpad.redhat.com> <51F11AFB.9040008@siemens.com> <1A5D30F9703985AD026648F0@nimrod.local> <20130726084345.GE31438@stefanha-thinkpad.redhat.com> <20130729085840.GC3721@dhcp-200-207.str.redhat.com> In-Reply-To: <20130729085840.GC3721@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alex Bligh , Stefan Hajnoczi , qemu-devel@nongnu.org, Liu Ping Fan , Stefan Hajnoczi , Jan Kiszka , Anthony Liguori Il 29/07/2013 10:58, Kevin Wolf ha scritto: > Am 26.07.2013 um 10:43 hat Stefan Hajnoczi geschrieben: >> On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote: >>> >>> >>> --On 25 July 2013 14:32:59 +0200 Jan Kiszka 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. > > But considering your first paragraph, why is it safe to let block jobs > running while we're migrating? Do we really do that? It sounds unsafe to > me. I think we should cancel them (synchronously) before the final bdrv_drain_all(). Paolo