Re: KVM call minutes for Sept 21

[Avi Kivity <avi@redhat.com>]

  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