From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6lp1-0003O4-BG for qemu-devel@nongnu.org; Sat, 07 Nov 2009 08:59:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6low-0003KU-Fy for qemu-devel@nongnu.org; Sat, 07 Nov 2009 08:59:18 -0500 Received: from [199.232.76.173] (port=49833 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6low-0003KL-8x for qemu-devel@nongnu.org; Sat, 07 Nov 2009 08:59:14 -0500 Received: from mail-yw0-f176.google.com ([209.85.211.176]:42756) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N6lov-00060J-UN for qemu-devel@nongnu.org; Sat, 07 Nov 2009 08:59:14 -0500 Received: by ywh6 with SMTP id 6so1584846ywh.4 for ; Sat, 07 Nov 2009 05:59:12 -0800 (PST) Message-ID: <4AF57D2C.9040600@codemonkey.ws> Date: Sat, 07 Nov 2009 07:59:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <20091105163702.GC21630@shareable.org> <4AF30129.7080203@us.ibm.com> <200911051820.48878.arnd@arndb.de> <4AF3154F.8090901@redhat.com> <4AF36DE9.3040803@us.ibm.com> <4AF3CF8C.1030408@redhat.com> <4AF44A33.6010602@us.ibm.com> <4AF53D8C.7080708@redhat.com> In-Reply-To: <4AF53D8C.7080708@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , Anthony Liguori , Arnd Bergmann , agl@linux.vnet.ibm.com, Arnd Bergmann , Juan Quintela , Dustin Kirkland , qemu-devel@nongnu.org, Michael Tsirkin Avi Kivity wrote: >> So it's equivalent to enabling dirty tracking during live migration. >> In my mind, if the cost associated with hot plug is a fraction of the >> cost of live migration, we're in good shape. > > I don't see why. Live migration is pretty expensive, but that doesn't > mean NIC hotplug should be. Deployments where live migration isn't a > concern (for example, performance critical guests that use device > assignment) don't suffer the live migration penalty so they shouldn't > expect to see a gratuitous NIC hotplug penalty that is a fraction of > that. Live migration is a feature that I expect will often be used in an automated fashion. IOW, there will be some background process that automatically migrates a VM to improve overall utilization in a cloud. NIC hotplug, on the other hand, will almost always be initiated by a user. If there's a cost associated with it, at least it's driven by a user action so it's something a user can plan for. >> Arguably, it's a much bigger problem for live migration. > > It is. I once considered switching live migration to shadow pte dirty > bit tracking instead of write protection, but ept doesn't have dirty > bits, so this will only help a minority of deployments by the time it > reaches users. > > So vfork() is required, or in light of its man page and glowing > recommendations from the security people, we can mark guest memory as > shared on fork and use plain fork(), like we do for pre mmu notifier > kernels. Indeed. Regards, Anthony Liguori