From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH][RFC] Prepare virtio for upstream QEMU merging Date: Tue, 14 Oct 2008 13:08:36 -0500 Message-ID: <48F4E024.70700@codemonkey.ws> References: <48F3934E.9040809@codemonkey.ws> <48F4C4FF.8020207@redhat.com> <48F4C6FF.4010801@codemonkey.ws> <48F4D74A.5090602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: Received: from rn-out-0910.google.com ([64.233.170.186]:39992 "EHLO rn-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751471AbYJNSIl (ORCPT ); Tue, 14 Oct 2008 14:08:41 -0400 Received: by rn-out-0910.google.com with SMTP id k40so1082281rnd.17 for ; Tue, 14 Oct 2008 11:08:40 -0700 (PDT) In-Reply-To: <48F4D74A.5090602@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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. I've posted virtio before on the qemu-devel and what has always been problematic are the various optimizations we do. They tend to cloud the actual implementation of virtio. I think taking this approach will make it all a lot easier. > 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. > Oh, and we need to set the dirty bit so live migration works. Or do we > have a hack in place to force copying of the ring at the last stage? > With the above fix, the rings accesses are no longer an issue. We just need to dirty memory in the scatter/gather lists on write. That's a very simple change and I'll include it in the next patch series. Regards, Anthony Liguori