Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Avi Kivity]

On 03/18/2010 12:10 PM, Ingo Molnar wrote:
> > It's not a 1:1 connection. There are more users of the KVM interface. To
> > name a few I'm aware of:
> >
> > - Mac-on-Linux (PPC)
> > - Dolphin (PPC)
> > - Xenner (x86)
> > - Kuli (s390)
> >      
> There must be a misunderstanding here: tools/perf/ still has a clear userspace
> interface and ABI. There's external projects making use of it: sysprof and
> libpfm (and probably more i dont know about it). Those projects are also
> contributing back.
>    

So it seems it is possible to scale the package wall.

> Still it's _very_ useful to have a single reference implementation under
> tools/perf/ where we concentrate the best of the code. That is where we make
> sure that each new kernel feature is appropriately implemented in user-space
> as well, that the combination works well together and is releasable to users.
> That is what keeps us all honest: the latency of features is much lower, and
> there's no ping-pong of blame going on between the two components in case of
> bugs or in case of misfeatures.
>    

That would make sense for a truly minimal userspace for kvm: we once had 
a tool called kvmctl which was used to run tests (since folded into 
qemu).  It didn't contain a GUI and was unable to run a general purpose 
guest.  It was a few hundred lines of code, and indeed patches to kvmctl 
had a much closer correspondence to patches with kvm (though still low, 
as most kvm patches don't modify the ABI).

> Same goes for KVM+Qemu: it would be so much nicer to have a single,
> well-focused reference implementation under tools/kvm/ and have improvements
> flow into that code base.
>
> That way KVM developers cannot just shrug "well, GUI suckage is a user-space
> problem" - like the answers i got in the KVM usability thread ...
>
> The buck will stop here.
>    

Suppose we copy qemu tomorrow into tools/.  All the problems will be 
copied with it.  Someone still has to write patches to fix them.  Who 
will it be?

> > The kernel/userspace interface really isn't the difficult part. Getting
> > device emulation working properly, easily and fast is.
> >      
> The kernel/userspace ABI is not difficult at all. Getting device emulation
> working properly, easily and fast indeed is. And my experience is that it is
> not working properly nor quickly at the moment, at all. (see the 'KVM
> usability' thread)
>
> Getting device emulation working properly often involves putting certain
> pieces that are currently done in Qemu into kernel-space. That kind of
> 'movement of emulation technology' from user-space component into the
> kernel-space component [or back] would very clearly be helped if those two
> components were in the same repository.
>    

Moving emulation into the kernel is indeed a problem.  Not because it's 
difficult, but because it indicates that the interfaces exposed to 
userspace are insufficient to obtain good performance.  We had that with 
vhost-net and I'm afraid we'll have that with vhost-blk.

> And i have first-hand experience there: we had (and have) similar scenarios
> with tools/perf routinely. We did some aspects in user-space, then decided to
> do it in kernel-space. Sometimes we moved kernel bits to user-space. It was
> very easy and there were no package and version complications as it's a single
> project. Sometimes we even moved bits back and forth until we found the right
> balance.
>    

That's reasonable in the first iterations of a project.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/