From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56275 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgMWr-0007er-IW for qemu-devel@nongnu.org; Tue, 03 Aug 2010 14:48:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgMWn-0007qP-02 for qemu-devel@nongnu.org; Tue, 03 Aug 2010 14:47:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37974) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgMWm-0007qG-Lt for qemu-devel@nongnu.org; Tue, 03 Aug 2010 14:47:52 -0400 Message-ID: <4C586452.90603@redhat.com> Date: Tue, 03 Aug 2010 21:47:46 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <20100803111306.GA21886@amd.home.annexia.org> <20100803113302.GT24773@redhat.com> <20100803121000.GV13789@amd.home.annexia.org> <20100803123714.GU24773@redhat.com> <20100803124808.GW13789@amd.home.annexia.org> <4C58176B.2050306@redhat.com> <20100803140506.GD22211@amd.home.annexia.org> <4C5829E1.60004@redhat.com> <20100803145337.GF22211@amd.home.annexia.org> <4C583F6A.7030600@redhat.com> <20100803162857.GX13789@amd.home.annexia.org> <4C584781.9040609@redhat.com> <4C5847CD.9080107@codemonkey.ws> <4C5848C7.3090806@redhat.com> <4C584982.5000108@codemonkey.ws> <4C584B66.5070404@redhat.com> <4C5854F1.3000905@codemonkey.ws> <4C5858B2.9090801@redhat.com> <4C585F5B.5070502@codemonkey.ws> <4C58635B.7020407@redhat.com> In-Reply-To: <4C58635B.7020407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, "Richard W.M. Jones" , Gleb Natapov , qemu-devel@nongnu.org On 08/03/2010 09:43 PM, Avi Kivity wrote: > Really, the bar on new interfaces (both to guest and host) should be > high, much higher than it is now. Interfaces should be well > documented, future proof, migration safe, and orthogonal to existing > interfaces. While the first three points could be improved with some > effort, adding a new dma interface is not going to be orthogonal to > virtio. And frankly, libguestfs is better off switching to one of the > other interfaces. Slurping huge initrds isn't the right way to do this. btw, precedent should play no role here. Just because an older interfaces wasn't documented or migration safe or unit-tested doesn't mean new ones get off the hook. It does help to have a framework in place that we can point people at, for example I added a skeleton Documentation/kvm/api.txt and some unit tests and then made contributors fill them in for new features. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.