Messages in this thread | | | Date | Thu, 18 Mar 2010 12:21:36 +0200 | From | Avi Kivity <> | Subject | Re: [RFC] Unify KVM kernel-space and user-space code into a single project |
| |
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
| |