From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM call minutes for Sept 21 Date: Sun, 26 Sep 2010 16:03:13 +0200 Message-ID: <4C9F52A1.1060306@redhat.com> References: <20100921180506.GI28009@x200.localdomain> <20100922000438.GA2844@fermat.math.technion.ac.il> <20100922090248.GD11145@redhat.com> <20100922162900.GA12492@fermat.math.technion.ac.il> <20100922174706.GA18005@redhat.com> <20100922192038.GK15338@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , "Nadav Har'El" , Chris Wright , kvm@vger.kernel.org To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15765 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756406Ab0IZOD1 (ORCPT ); Sun, 26 Sep 2010 10:03:27 -0400 In-Reply-To: <20100922192038.GK15338@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 09/22/2010 09:20 PM, Joerg Roedel wrote: > On Wed, Sep 22, 2010 at 07:47:06PM +0200, Gleb Natapov wrote: > > On Wed, Sep 22, 2010 at 06:29:00PM +0200, Nadav Har'El wrote: > > > > In any case, while I obviously agree that it's your prerogative not to merge > > > code that you consider ugly, I still don't see any particular problem to start > > > with the current, working, code, and fix it later. It's not like we can never > > > change this code after it's in - it's clearly marked with if(nested) and > > > doesn't effect anything in the non-nested path. > > > > > After code it merged there is much less incentive to change things > > drastically. > > I think nested svm is a good counter example to that. It has drastically > improved since it was merged. Ok, it hasn't _changed_ drastically, but > what drastic changes do we expect to become necessary in the nested-vmx > code? > I don't expect drastic changes, but then, I still don't understand it well. Part of the review process is the maintainer becoming familiar (and, in some cases, comfortable) with the code. The nit-picking is often just me proving to myself that I understand what's happening. btw, speaking of drastic changes to nsvm, one thing I'd like to see is the replacement of those kmaps with something like put_user_try() and put_user_catch(). It should be as fast (or faster) than kmaps, and not affect preemptibility. -- error compiling committee.c: too many arguments to function