From mboxrd@z Thu Jan 1 00:00:00 1970
From: Pavel Fedin
Subject: RE: [Qemu-devel] Live migration sequence
Date: Tue, 13 Oct 2015 15:41:42 +0300
Message-ID: <00e001d105b4$83c62c70$8b528550$@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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path:
Received: from localhost (localhost [127.0.0.1])
by mm01.cs.columbia.edu (Postfix) with ESMTP id 54F6C41145
for ; Tue, 13 Oct 2015 08:39:34 -0400 (EDT)
Received: from mm01.cs.columbia.edu ([127.0.0.1])
by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zr0KcCjBrJ4J for ;
Tue, 13 Oct 2015 08:39:32 -0400 (EDT)
Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com
[210.118.77.12])
by mm01.cs.columbia.edu (Postfix) with ESMTPS id 771A24113E
for ; Tue, 13 Oct 2015 08:39:32 -0400 (EDT)
Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245])
by mailout2.w1.samsung.com
(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014))
with ESMTP id <0NW5005VUSLJ1E80@mailout2.w1.samsung.com> for
kvmarm@lists.cs.columbia.edu; Tue, 13 Oct 2015 13:41:43 +0100 (BST)
In-reply-to:
Content-language: ru
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: kvmarm-bounces@lists.cs.columbia.edu
Sender: kvmarm-bounces@lists.cs.columbia.edu
To: 'Peter Maydell'
Cc: 'Juan Quintela' , 'Marc Zyngier' , 'QEMU' , "'Dr. David Alan Gilbert'" , 'Amit Shah' , kvmarm@lists.cs.columbia.edu
List-Id: kvmarm@lists.cs.columbia.edu
Hello!
> 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).
Yes, you're right. Looks like this would be more complicated but better way to do the thing. I'll look at migration state notifier mechanism.
> But we wanted to get the basic no-ITS ABI sorted out and agreed first
Yes, this is good idea, too much changes otherwise. But here at Samsung we have a project, and it has deadlines, so please understand that i try to do things quickly.
Of course, you see that as soon as i make something, i post it at least as RFCs, because i don't want to have something misdesigned, which will be dropped afterwards. Cooperation with OSS is one of goals of our project.
Thank you very much for your cooperation and explanations.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia