From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhm6a-0003GS-IV for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:55:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rhm6Z-0000Dw-Ix for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:55:28 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:45535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhm6Z-0000Ds-F9 for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:55:27 -0500 Received: by ggnk1 with SMTP id k1so11341969ggn.4 for ; Mon, 02 Jan 2012 09:55:27 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F01EF86.2050600@redhat.com> Date: Mon, 02 Jan 2012 18:55:18 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4EFC634E.10406@redhat.com> <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> In-Reply-To: <20120102170551.GF4172@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Andrea Arcangeli Cc: kvm@vger.kernel.org, satoshi.itoh@aist.go.jp, t.hirofuchi@aist.go.jp, qemu-devel@nongnu.org, Isaku Yamahata , Avi Kivity On 01/02/2012 06:05 PM, Andrea Arcangeli wrote: > On Thu, Dec 29, 2011 at 06:01:45PM +0200, Avi Kivity wrote: >> On 12/29/2011 06:00 PM, Avi Kivity wrote: >>> The NFS client has exactly the same issue, if you mount it with the intr >>> option. In fact you could use the NFS client as a trivial umem/cuse >>> prototype. >> >> Actually, NFS can return SIGBUS, it doesn't care about restarting daemons. > > During KVMForum I suggested to a few people that it could be done > entirely in userland with PROT_NONE. Or MAP_NORESERVE. Anything you do that is CUSE-based should be doable in a separate QEMU thread (rather than a different process that talks to CUSE). If a userspace CUSE-based solution could be done with acceptable performance, the same thing would have the same or better performance if done entirely within QEMU. > So the problem is if we do it in > userland with the current functionality you'll run out of VMAs and > slowdown performance too much. > > But all you need is the ability to map single pages in the address > space. Would this also let you set different pgprots for different pages in the same VMA? It would be useful for write barriers in garbage collectors (such as boehm-gc). These do not have _that_ many VMAs, because every GC cycles could merge all of them back to a single VMA with PROT_READ permissions; however, they still put some strain on the VM subsystem. Paolo