Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Ingo Molnar on 18 Mar 2010 07:40 * Avi Kivity <avi(a)redhat.com> wrote: > > 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). If it's functional to the extent of at least allowing say a serial console via the console (like the UML binary allows) i'd expect the minimal user-space to quickly grow out of this minimal state. The rest will be history. Maybe this is a better, simpler (and much cleaner and less controversial) approach than moving a 'full' copy of qemu there. There's certainly no risk: if qemu stays dominant then nothing is lost [tools/kvm/ can be removed after some time], and if this clean base works out fine then the useful qemu technologies will move over to it gradually and without much fuss, and the developers will move with it as well. If it's just a token effort with near zero utility to begin with it certainly wont take off. Once it's there in tools/kvm/ and bootable i'd certainly hack up some quick xlib based VGA output capability myself - it's not that hard ;-) It would also allow me to test whether latest-KVM still boots fine in a much simpler way. (most of my testboxes dont have qemu installed) So you have one user signed up for that already ;-) > > 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? What we saw with tools/perf/ was that pure proximity to actual kernel testers and kernel developers produces a steady influx of new developers. It didnt happen overnight, but it happened. A simple: cd tools/perf/ make -j install Gets them something to play with. That kind of proximity is very powerful. The other benefit was that distros can package perf with the kernel package, so it's updated together with the kernel. This means a very efficient distribution of new technologies, together with new kernel releases. Distributions are very eager to update kernels even in stable periods of the distro lifetime - they are much less willing to update user-space packages. You can literally get full KVM+userspace features done _and deployed to users_ within the 3 months development cycle of upstream KVM. All these create synergies that are very clear once you see the process in motion. It's a powerful positive feedback loop. Give it some thought please. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 18 Mar 2010 07:50 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/18/2010 12:50 PM, Ingo Molnar wrote: > >* Avi Kivity<avi(a)redhat.com> wrote: > > > >>>The moment any change (be it as trivial as fixing a GUI detail or as > >>>complex as a new feature) involves two or more packages, development speed > >>>slows down to a crawl - while the complexity of the change might be very > >>>low! > >>Why is that? > > It's very simple: because the contribution latencies and overhead compound, > > almost inevitably. > > It's not inevitable, if the projects are badly run, you'll have high > latencies, but projects don't have to be badly run. So the 64K dollar question is, why does Qemu still suck? > > >If you ever tried to implement a combo GCC+glibc+kernel feature you'll know > >... > > > >Even with the best-run projects in existence it takes forever and is very > >painful - and here i talk about first hand experience over many years. > > Try sending a patch to qemu-devel@, you may be pleasantly surprised. > > > >>I the maintainers of all packages are cooperative and responsive, then the > >>patches will get accepted quickly. If they aren't, development will be > >>slow. [...] > >I'm afraid practice is different from the rosy ideal you paint there. Even > >with assumed 'perfect projects' there's always random differences between > >projects, causing doubled (tripled) overhead and compounded up overhead: > > > > - random differences in release schedules > > > > - random differences in contribution guidelines > > > > - random differences in coding style > > None of these matter for steady contributors. > > >>[...] It isn't any different from contributing to two unrelated kernel > >>subsystems (which are in fact in different repositories until the next merge > >>window). > >You mention a perfect example: contributing to multipe kernel subsystems. Even > >_that_ is very noticeably harder than contributing to a single subsystem - due > >to the inevitable buerocratic overhead, due to different development trees, > >due to different merge criteria. > > > >So you are underlining my point (perhaps without intending to): treating > >closely related bits of technology as a single project is much better. > > > > Obviously arch/x86/kvm/, virt/ and tools/kvm/ should live in a single > > development repository (perhaps micro-differentiated by a few topical > > branches), for exactly those reasons you mention. > > How is a patch for the qemu GUI eject button and the kvm shadow mmu related? > Should a single maintainer deal with both? We have co-maintainers for perf that have a different focus. It works pretty well. Look at git log tools/perf/ and how user-space and kernel-space components interact in practice. You'll patches that only impact one side, but you'll see very big overlap both in contributor identity and in patches as well. Also, let me put similar questions in a bit different way: - ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? ' - ' how is the in-kernel dynticks implementation related to Qemu's implementation of hardware timers? ' - ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu eject event? ' - ' how is a new hardware virtualization feature related to being able to configure and use it via Qemu? ' - ' how is the in-kernel x86 decoder/emulator related to the Qemu x86 emulator? ' - ' how is the performance of the qemu GUI related to the way VGA buffers are mapped and accelerated by KVM? ' They are obviously deeply related. The quality of a development process is not defined by the easy cases where no project unification is needed. The quality of a development process is defined by the _difficult_ cases. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Graf on 18 Mar 2010 08:10 Ingo Molnar wrote: > * Avi Kivity <avi(a)redhat.com> wrote: > > >>> 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). >> > > If it's functional to the extent of at least allowing say a serial console via > the console (like the UML binary allows) i'd expect the minimal user-space to > quickly grow out of this minimal state. The rest will be history. > > Maybe this is a better, simpler (and much cleaner and less controversial) > approach than moving a 'full' copy of qemu there. > > There's certainly no risk: if qemu stays dominant then nothing is lost > [tools/kvm/ can be removed after some time], and if this clean base works out > fine then the useful qemu technologies will move over to it gradually and > without much fuss, and the developers will move with it as well. > > If it's just a token effort with near zero utility to begin with it certainly > wont take off. > > Once it's there in tools/kvm/ and bootable i'd certainly hack up some quick > xlib based VGA output capability myself - it's not that hard ;-) It would also > allow me to test whether latest-KVM still boots fine in a much simpler way. > (most of my testboxes dont have qemu installed) > > So you have one user signed up for that already ;-) > Alright, you just volunteered. Just give it a go and try to implement the "oh so simple" KVM frontend while maintaining compatibility with at least a few older Linux guests. My guess is that you'll realize it's a dead end before committing anything to the kernel source tree. But really, just try it out. Good Luck Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 18 Mar 2010 08:30 On 03/18/2010 01:48 PM, Ingo Molnar wrote: > >> It's not inevitable, if the projects are badly run, you'll have high >> latencies, but projects don't have to be badly run. >> > So the 64K dollar question is, why does Qemu still suck? > Where people sent patches, it doesn't suck (or sucks less). Where they don't, it still sucks. And it cost way more than $64K. If moving things to tools/ helps, let's move Fedora to tools/. >> How is a patch for the qemu GUI eject button and the kvm shadow mmu related? >> Should a single maintainer deal with both? >> > We have co-maintainers for perf that have a different focus. It works pretty > well. > And it works well when I have patches that change x86 core and kvm. But that's no longer a single repository and we have to coordinate. > Look at git log tools/perf/ and how user-space and kernel-space components > interact in practice. You'll patches that only impact one side, but you'll see > very big overlap both in contributor identity and in patches as well. > > Also, let me put similar questions in a bit different way: > > - ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? ' > Both implement the same spec. One is be a code derivative of the other (via Xen). > - ' how is the in-kernel dynticks implementation related to Qemu's > implementation of hardware timers? ' > The quality of host kernel timers directly determines the quality of qemu's timer emulation. > - ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu > eject event? ' > Both implement the same spec. The kernel of course needs to handle all implementation variants, while qemu only needs to implement it once. > - ' how is a new hardware virtualization feature related to being able to > configure and use it via Qemu? ' > Most features (example: npt) are transparent to userspace, some are not. When they are not, we introduce an ioctl() to kvm for controlling the feature, and a command-line switch to qemu for calling it. > - ' how is the in-kernel x86 decoder/emulator related to the Qemu x86 > emulator? ' > Both implement the same spec. Note qemu is not an emulator but a binary translator. > - ' how is the performance of the qemu GUI related to the way VGA buffers are > mapped and accelerated by KVM? ' > kvm needs to support direct mapping when possible and efficient data transfer when not. The latter will obviously be much slower. When direct mapping is possible, kvm needs to track pages touched by the guest to avoid full screen redraws. The rest (interfacing to X or vnc, implementing emulated hardware acceleration, full-screen mode, etc.) are unrelated. > They are obviously deeply related. Not at all. kvm in fact knows nothing about vga, to take your last example. To suggest that qemu needs to be close to the kernel to benefit from the kernel's timer implementation means we don't care about providing quality timing except to ourselves, which luckily isn't the case. Some time ago the various desktops needed directory change notification, and people implemented inotify (or whatever it's called today). No one suggested tools/gnome/ and tools/kde/. > The quality of a development process is not > defined by the easy cases where no project unification is needed. The quality > of a development process is defined by the _difficult_ cases. > That's true, but we don't have issues at the qemu/kvm boundary. Note we do have issues at the qemu/aio interfaces and qemu/net interfaces (out of which vhost-net was born) but these wouldn't be solved by tools/qemu/. -- 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 18 Mar 2010 09:10
* Frank Ch. Eigler <fche(a)redhat.com> wrote: > Ingo Molnar <mingo(a)elte.hu> writes: > > > [...] > > Distributions are very eager to update kernels even in stable periods of the > > distro lifetime - they are much less willing to update user-space packages. > > [...] > > Sorry, er, what? What distributions eagerly upgrade kernels in stable > periods, were it not primarily motivated by security fixes? [...] Please check the popular distro called 'Fedora' for example, and its kernel upgrade policies. > [...] What users eagerly replace their kernels? Those 99% who click on the 'install 193 updates' popup. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |