From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyHV-0007PK-OI for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:02:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlyHQ-0000aQ-1k for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:02:13 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:9344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyHP-0000aM-S5 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:02:07 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NW50018DQRH5C20@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 13 Oct 2015 13:02:05 +0100 (BST) From: Pavel Fedin References: <008b01d101be$0228d720$067a8560$@samsung.com> <20151009152942.GF2702@work-vm> <00b801d1059e$d6d4ffb0$847eff10$@samsung.com> <20151013110527.GB2555@work-vm> In-reply-to: <20151013110527.GB2555@work-vm> Date: Tue, 13 Oct 2015 15:02:03 +0300 Message-id: <00d801d105ae$fa1eb5a0$ee5c20e0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-language: ru Subject: Re: [Qemu-devel] Live migration sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "'Dr. David Alan Gilbert'" Cc: peter.maydell@linaro.org, quintela@redhat.com, marc.zyngier@arm.com, 'QEMU' , amit.shah@redhat.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org Hello! > b) Once you're in the device state saving (a above) you must not change guest RAM, > because at that point the migration code won't send any new changes across > to the destination. So any sync's you're going to do have to happen before/at > the time we stop the CPU and do the final RAM sync. On the plus side, when > you're loading the device state in (a) you can be sure the RAM contents are there. This is good. I think, in this case i can teach the kernel (here we talk about accelerated in-kernel irqchip implementation) to flush ITS caches when a CPU is stopped. This will do the job. > c) Watch out for the size of that final sync; if you have lots of these ITS > and they all update their 64k page at the point we stop the CPU then you're > going to generate a lot of RAM that needs syncing. Well, reducing downtime would be the next task. :) First i'd like to get it working at all. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia