From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyKX-0000cH-Rz for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlyKT-0001ZN-E8 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:05:21 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:35170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyKT-0001ZJ-AR for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:05:17 -0400 Received: by vkha6 with SMTP id a6so8585378vkh.2 for ; Tue, 13 Oct 2015 05:05:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <00d801d105ae$fa1eb5a0$ee5c20e0$@samsung.com> References: <008b01d101be$0228d720$067a8560$@samsung.com> <20151009152942.GF2702@work-vm> <00b801d1059e$d6d4ffb0$847eff10$@samsung.com> <20151013110527.GB2555@work-vm> <00d801d105ae$fa1eb5a0$ee5c20e0$@samsung.com> From: Peter Maydell Date: Tue, 13 Oct 2015 13:04:57 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] Live migration sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin Cc: Juan Quintela , Marc Zyngier , QEMU , "Dr. David Alan Gilbert" , Amit Shah , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall On 13 October 2015 at 13:02, Pavel Fedin wrote: > 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. Our idea at the discussion at Connect was to have an ioctl to request a flush, rather than to do it automatically when a CPU is stopped (you probably don't want to flush when only one CPU in an SMP system is stopped, for instance). But we wanted to get the basic no-ITS ABI sorted out and agreed first, so those details aren't in the patch Christoffer sent out the other day. It will probably be more efficient if we agree on the ABI details here before doing the implementation rather than afterwards. thanks -- PMM