From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlLCS-00088x-D0 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:00:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlLCI-0005zQ-Sw for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:00:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlLCI-0005yC-K7 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:00:06 -0500 Message-ID: <4F0EE75F.3020306@redhat.com> Date: Thu, 12 Jan 2012 15:59:59 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111229134920.GH19274@valinux.co.jp> <4EFC70BA.1080808@redhat.com> <20111229141802.GI19274@valinux.co.jp> <4EFC7AB8.807@redhat.com> <20111229144943.GJ19274@valinux.co.jp> <4EFC7F4F.9010202@redhat.com> <20111229155328.GK19274@valinux.co.jp> <4EFC8EAD.80306@redhat.com> <4EFC8EE9.9030802@redhat.com> <20120102170551.GF4172@redhat.com> <20120104030355.GL19274@valinux.co.jp> In-Reply-To: <20120104030355.GL19274@valinux.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Isaku Yamahata Cc: Andrea Arcangeli , t.hirofuchi@aist.go.jp, qemu-devel@nongnu.org, kvm@vger.kernel.org, satoshi.itoh@aist.go.jp On 01/04/2012 05:03 AM, Isaku Yamahata wrote: > Yes, it's quite doable in user space(qemu) with a kernel-enhancement. > And it would be easy to convert a separated daemon process into a thread > in qemu. > > I think it should be done out side of qemu process for some reasons. > (I just repeat same discussion at the KVM-forum because no one remembers > it) > > - ptrace (and its variant) > Some people want to investigate guest ram on host (qemu stopped or lively). > For example, enhance crash utility and it will attach qemu process and > debug guest kernel. To debug the guest kernel you don't need to stop qemu itself. I agree it's a problem for qemu debugging though. > > - core dump > qemu process may core-dump. > As postmortem analysis, people want to investigate guest RAM. > Again enhance crash utility and it will read the core file and analyze > guest kernel. > When creating core, the qemu process is already dead. Yes, strong point. > It precludes the above possibilities to handle fault in qemu process. I agree. -- error compiling committee.c: too many arguments to function