From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya2t7-0002Kx-J4 for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:59:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya2t3-0002vY-G5 for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:59:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya2t3-0002vS-Ao for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:59:25 -0400 Message-ID: <55101C22.6040108@redhat.com> Date: Mon, 23 Mar 2015 14:58:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1427088255-29885-1-git-send-email-famz@redhat.com> <20150323135612.GI9268@stefanha-thinkpad.redhat.com> In-Reply-To: <20150323135612.GI9268@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] block: Switch to host monotonic clock for IO throttling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Fam Zheng Cc: Kevin Wolf , berto@igalia.com, qemu-devel@nongnu.org, Stefan Hajnoczi On 23/03/2015 14:56, Stefan Hajnoczi wrote: > On Mon, Mar 23, 2015 at 01:24:15PM +0800, Fam Zheng wrote: >> Currently, throttle timers won't make any progress when VCPU is not >> running, which would stall the request queue in utils, qtest, vm >> suspending, and live migration without special handling. >> >> For example in bdrv_drain_all, all requests are resumed immediately >> without taking throttling limit into account. This means whenever it is >> called, IO throttling goes ineffective (examples: system reset, >> migration and many block job operations.). >> >> This might be some loophole that guest could exploit. >> >> If we use the host clock, we can later just trust the nested poll when >> waiting for requests. >> >> Note that for qemu-iotests case 093, which sets up qtest when running >> QEMU, we still use vm clock so the script can control the clock stepping >> in order to be deterministic. >> >> Signed-off-by: Fam Zheng >> >> --- >> v2: Don't break qemu-iotests 093. >> --- >> block.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) > > Should we make an exception for live migration to reduce downtime? > > I'm concerned that now vm_stop() can take even longer since we'll wait > for throttling. What would have prevented the wait before? (In fact I'm not sure why we would have even terminated bdrv_drain_all, since we run it when QEMU_CLOCK_VIRTUAL is not advancing anymore!). Paolo