From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaeyong Yoo Subject: Re: [PATCH RFC 0/4] arm: regarding live migration Date: Thu, 13 Jun 2013 01:15:48 +0000 (GMT) Message-ID: <30392061.196241371086148236.JavaMail.weblogic@epml12> Reply-To: jaeyong.yoo@samsung.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: MIME-version: 1.0 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Hello Ian, I got some more questions while implementing live migration in arm. > > (3) Regarding split drivers, come to think of it, we have to store > > both side (front/back) states, in-flight event channels, IRQs, etc. > > And those look like quite a work (although evtchn is migrated within vcpu) > > I appreciate if you guys could share any hints from the experience of > > migrating split drivers in x86. > > There is no need to save any of this state, the devices are effectively > reconnected from scratch on the destination and the frontend devices are > responsible for replaying any inflight state on resume. > I'm trying to find the suspending part of PV driver, but can not locate it. (And, looks like there is no function like suspend in xen-blkfront.c) One guess is by deleting vbd in xenstore, maybe hot-plug-out can suspend. Could you give me some advice? And, about grant table, if we effectively suspend and resume PV driver, I think we don't need to migrate grant table entires. Is this right? Thanks, Jaeyong