From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgE6J-00036d-0G for qemu-devel@nongnu.org; Thu, 29 Dec 2011 06:24:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgE6E-0002WO-2M for qemu-devel@nongnu.org; Thu, 29 Dec 2011 06:24:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgE6C-0002To-FP for qemu-devel@nongnu.org; Thu, 29 Dec 2011 06:24:40 -0500 Message-ID: <4EFC4DF0.2040708@redhat.com> Date: Thu, 29 Dec 2011 13:24:32 +0200 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: 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: t.hirofuchi@aist.go.jp, qemu-devel@nongnu.org, kvm@vger.kernel.org, satoshi.itoh@aist.go.jp On 12/29/2011 03:26 AM, Isaku Yamahata wrote: > This is Linux kernel driver for qemu/kvm postcopy live migration. > This is used by qemu/kvm postcopy live migration patch. > > TODO: > - Consider FUSE/CUSE option > So far several mmap patches for FUSE/CUSE are floating around. (their > purpose isn't different from our purpose, though). They haven't merged > into the upstream yet. > The driver specific part in qemu patches is modularized. So I expect it > wouldn't be difficult to switch kernel driver to CUSE based driver. It would be good to get more input about this, please involve lkml and the FUSE/CUSE people. > ioctl commands: > > UMEM_DEV_CRATE_UMEM: create umem device for qemu > UMEM_DEV_LIST: list created umem devices > UMEM_DEV_REATTACH: re-attach the created umem device > UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when > the process that services page fault disappears or get stack. > Then, administrator can list the umem devices and unblock > the process which is waiting for page. Ah, I asked about this in my patch comments. I think this is done better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a new process. Introducing a global namespace has a lot of complications attached. > > UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process > UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source > for daemon > > UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process > This is _NOT_ implemented yet. > anonymous I'm not sure whether this can be implemented > or not. How do we find out? This is fairly important, stuff like transparent hugepages and ksm only works on anonymous memory. -- error compiling committee.c: too many arguments to function