From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][RFC] Prepare virtio for upstream QEMU merging Date: Wed, 15 Oct 2008 15:57:49 +0200 Message-ID: <48F5F6DD.4020402@redhat.com> References: <48F3934E.9040809@codemonkey.ws> <48F4C4FF.8020207@redhat.com> <48F4C6FF.4010801@codemonkey.ws> <48F4D74A.5090602@redhat.com> <48F4E024.70700@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39679 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751839AbYJON5y (ORCPT ); Wed, 15 Oct 2008 09:57:54 -0400 In-Reply-To: <48F4E024.70700@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: >>>> Why not merge these bits prior to merging virtio? They aren't kvm >>>> specific and would be good in mainline qemu. >>>> >>> I'd rather have a consumer of an interface before merging the actual >>> infrastructure. >>> >>> >> >> So merge them all into qemu at the same time (as separate patches, if >> you like). >> > > But that will require refactoring a lot of these optimizations. In > order to do that right, they need to be presented on qemu-devel. It's > a whole lot easier to do that incrementally so that people can digest > it all instead of blasting a big series. Can you elaborate? Which interfaces will need rework, and why? > >> The amount of code duplication is frightening. >> > > I've already got that worked out. I need to prepare and commit a > patch to fix stw/lduw in upstream QEMU and then we can switch to > always using those functions in KVM. I've done some performance > testing and that seems to be enough. With that, there is no longer > any scary code duplication. Yes, your patch on qemu-devel looks good. Even if we do have a performance problem (which may well turn out after we optimize things some more), it's easy to have a cached pointer along with the phys address. -- error compiling committee.c: too many arguments to function