From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgHIh-00042s-Td for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:49:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgHIg-0008Mb-Sa for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:49:47 -0500 Received: from mail.valinux.co.jp ([210.128.90.3]:51381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgHIg-0008MJ-GL for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:49:46 -0500 Date: Thu, 29 Dec 2011 23:49:43 +0900 From: Isaku Yamahata Message-ID: <20111229144943.GJ19274@valinux.co.jp> References: <4EFC4DF0.2040708@redhat.com> <20111229123922.GG19274@valinux.co.jp> <4EFC634E.10406@redhat.com> <20111229134920.GH19274@valinux.co.jp> <4EFC70BA.1080808@redhat.com> <20111229141802.GI19274@valinux.co.jp> <4EFC7AB8.807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFC7AB8.807@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andrea Arcangeli , t.hirofuchi@aist.go.jp, qemu-devel@nongnu.org, kvm@vger.kernel.org, satoshi.itoh@aist.go.jp On Thu, Dec 29, 2011 at 04:35:36PM +0200, Avi Kivity wrote: > On 12/29/2011 04:18 PM, Isaku Yamahata wrote: > > > > > > > > The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE or > > > > TASK_UNINTERRUPTIBLE. > > > > I can think of several options. > > > > - When daemon X is dead, all page faults are served by zero pages. > > > > - When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS > > > > - list/reattach: complications. You don't like it > > > > - other? > > > > > > Don't resolve the page fault. It's up to the user/system to make sure > > > it happens. qemu can easily do it by watching for the daemon's death > > > and respawning it. > > > > > > When the new daemon is started, it can ask the kernel for a list of > > > pending requests, and service them. > > > > Great, then we agreed with list/reattach basically. > > (Maybe identity scheme needs reconsideration.) > > I guess we miscommunicated. Why is reattach needed? If you have the > fd, nothing else is needed. What if malicious process close the fd and does page fault intentionally? Unkillable process issue remains. I think we are talking not only qemu case but also general case. -- yamahata