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: Avi Kivity on 22 Mar 2010 13:50 On 03/22/2010 06:32 PM, Ingo Molnar wrote: > > So, what do you think creates code communities and keeps them alive? > Developers and code. And the wellbeing of developers are primarily influenced > by the repository structure and by the development/maintenance process - i.e. > by the 'fun' aspect. (i'm simplifying things there but that's the crux of it.) > There is nothing fun about having one repository or two. Who cares about this anyway? tools/kvm/ probably will draw developers, simply because of the glory associated with kernel work. That's a bug, not a feature. It means that effort is not distributed according to how it's needed, but because of irrelevant considerations. > I simply do not want to see KVM face the same fate, and yes i do see similar > warnings signs. > The number of kvm and qemu developers keeps increasing. We're having a kvm forum in August where we all meet. Come and see for yourself. >> We actually have lguest which is small. But it lacks functionality and the >> developer community KVM has attracted. >> > I suggested long ago to merge lguest into KVM to cover non-VMX/non-SVM > execution. > Rusty posted some initial patches for pv-only kvm but he lost interest before they were completed. No one followed up. btw, lguest has a single repository, userspace and kernel in the same repository, yet is practically dead. >>> I think you are rationalizing the status quo. >>> >> I see that there are issues with KVM today in some areas. You pointed out >> the desktop usability already. I personally have trouble with the >> qem-kvm.git because it is unbisectable. But repository unification doesn't >> solve the problem here. >> > Why doesnt it solve the bisectability problem? The kernel repo is supposed to > be bisectable so that problem would be solved. > These days qemu-kvm.git is bisectable (though not always trivially). qemu.git doesn't have this problem. >> The point for a single repository is that it simplifies the development >> process. I agree with you here. But the current process of KVM is not too >> difficult after all. I don't have to touch qemu sources for most of my work >> on KVM. >> > In my judgement you'd have to do that more frequently, if KVM was properly > weighting its priorities. For example regarding this recent KVM commit of > yours: > > | commit ec1ff79084fccdae0dca9b04b89dcdf3235bbfa1 > | Author: Joerg Roedel<joerg.roedel(a)amd.com> > | Date: Fri Oct 9 16:08:31 2009 +0200 > | > | KVM: SVM: Add tracepoint for invlpga instruction > | > | This patch adds a tracepoint for the event that the guest > | executed the INVLPGA instruction. > > With integrated KVM tooling i might have insisted for that new tracepoint to > be available to users as well via some more meaningful tooling than just a > pure tracepoint. > Something I've wanted for a long time is to port kvm_stat to use tracepoints instead of the home-grown instrumentation. But that is unrelated to this new tracepoint. Other than that we're satisfied with ftrace. > You should realize that naturally developers will gravitate towards the most > 'fun' aspects of a project. It is the task of the maintainer to keep the > balance between fun and utility, bugs and features, quality and code-rot. > There are plenty of un-fun tasks (like fixing bugs and providing RAS features) that we're doing. We don't do this for fun but to satisfy our users. -- 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: Avi Kivity on 22 Mar 2010 14:00 On 03/22/2010 07:34 PM, Ingo Molnar wrote: > >> The 'something trustable and kernel-provided'. The kernel knows nothing >> about guest names. >> > The kernel certainly knows about other resources such as task names or network > interface names or tracepoint names. This is kernel design 101. > But it doesn't know about guest names. You can't trust task names since any user can create a task with any name. Network interfaces are root only so you can trust their names. There are dozens or even hundreds of object classes the kernel does not know about and cannot enumerate. User names, for instance. X sessions. Windows (the screen artifact, not the OS). CIFS shares exported by this machine. Currently running applications (not processes). btw, network interfaces would have been much better of using /dev/netif/name rather than having their own namespace, IMO, like disks. >>>> [...] I don't like using the term, because sometimes the layers are >>>> incorrect and need to be violated. But it should be done explicitly, not >>>> as a shortcut for a minor feature (and profiling is a minor feature, most >>>> users will never use it, especially guest-from-host). >>>> >>>> The fact is we have well defined layers today, kvm virtualizes the cpu >>>> and memory, qemu emulates devices for a single guest, libvirt manages >>>> guests. We break this sometimes but there has to be a good reason. So >>>> perf needs to talk to libvirt if it wants names. Could be done via >>>> linking, or can be done using a pluging libvirt drops into perf. >>>> > This is really just the much-discredited microkernel approach for keeping > global enumeration data that should be kept by the kernel ... > I disagree it should be kept in the kernel. Why introduce a new namespace, with APIs to query it, manage it, rules regarding conflicts, then virtualize it for containers. > Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by Anthony. > There's numerous ways that this can break: > I don't like it either. We have libvirt for enumerating guests. > - Those special files can get corrupted, mis-setup, get out of sync, or can > be hard to discover. > > - The ${HOME}/.qemu/qmp/ solution suggested by Anthony has a very obvious > design flaw: it is per user. When i'm root i'd like to query _all_ current > guest images, not just the ones started by root. A system might not even > have a notion of '${HOME}'. > > - Apps might start KVM vcpu instances without adhering to the > ${HOME}/.qemu/qmp/ access method. > - it doesn't work with nfs. > - There is no guarantee for the Qemu process to reply to a request - while > the kernel can always guarantee an enumeration result. I dont want 'perf > kvm' to hang or misbehave just because Qemu has hung. > If qemu doesn't reply, your guest is dead anyway. > Really, for such reasons user-space is pretty poor at doing system-wide > enumeration and resource management. Microkernels lost for a reason. > Take a look at your desktop, userspace is doing all of that everywhere, from enumerating users and groups, to deciding how your disks are named. The kernel only provides the bare facilities. > You are committing several grave design mistakes here. > I am committing on the shoulders of giants. -- 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: Avi Kivity on 22 Mar 2010 14:00 On 03/22/2010 07:39 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/22/2010 07:27 PM, Pekka Enberg wrote: >> >>> It's kinda funny to see people argue that having an external repository is >>> not a problem and that it's not a big deal if building something from the >>> repository is slightly painful as long as it doesn't require a PhD when we >>> have _real world_ experience that it _does_ limit developer base in some >>> cases. Whether or not that applies to kvm remains to be seen but I've yet >>> to see a convincing argument why it doesn't. >>> >> qemu has non-Linux developers. Not all of their contributions are relevant >> to kvm but some are. If we pull qemu into tools/kvm, we lose them. >> > Qemu had very few developers before KVM made use of it - i know it because i > followed the project prior KVM. > No argument. > So whatever development activitity Qemu has today, it's 99% [WAG] attributable > to KVM. It might have non-Linux contributors, but they wouldnt be there if it > wasnt for all the Linux contributors ... > > Furthermore, those contributors wouldnt have to leave - they could simply use > a different Git URI ... > tools/kvm would drop support for non-Linux hosts, for tcg, and for architectures which kvm doesn't support ("clean and minimal"). That would be the real win, not sharing the repository. But those other contributors would just stay with the original 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: Avi Kivity on 22 Mar 2010 14:10 On 03/22/2010 07:43 PM, Ingo Molnar wrote: > >> It's kinda funny to see people argue that having an external repository is >> not a problem and that it's not a big deal if building something from the >> repository is slightly painful as long as it doesn't require a PhD when we >> have _real world_ experience that it _does_ limit developer base in some >> cases. Whether or not that applies to kvm remains to be seen but I've yet to >> see a convincing argument why it doesn't. >> > Yeah. > > Also, if in fact the claim that the 'repository does not matter' is true then > it doesnt matter that it's hosted in tools/kvm/ either, right? > Again, the second it's moved to tools/kvm/ we strip it off anything that kvm can't use. > I.e. it's a win-win situation. Worst-case nothing happens beyond a Git URI > change. Best-case the project is propelled to never seen heights due to > contribution advantages not contemplated and not experienced by the KVM guys > before ... > You're exaggerating. There were 773 commits into qemu.git (excluding qemu-kvm.git) in the past three months. 162 for the same period for tools/perf. The pool is not that deep. -- 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: Avi Kivity on 22 Mar 2010 14:20
On 03/22/2010 04:47 PM, Ingo Molnar wrote: > >>> If you are interested in the first-hand experience of the people who are >>> doing the perf work then here it is: by far the biggest reason for perf >>> success and perf usability is the integration of the user-space tooling >>> with the kernel-space bits, into a single repository and project. >>> >> Please take a look at the kvm integration code in qemu as a fraction of the >> whole code base. >> > You have to admit that much of Qemu's past 2-3 years of development was > motivated by Linux/KVM (i'd say more than 50% of the code). kvm certainly revitalized qemu development. > As such it's one > and the same code base - you just continue to define Qemu to be different from > KVM. > It's not the same code base. kvm provides a cpu virtualization service, qemu uses it. There could be other users. qemu could go away one day and be replaced by something else (tools/kvm?), and kvm would be unaffected. > I very much remember how Qemu looked like _before_ KVM: it was a struggling, > dying project. KVM clearly changed that. > I'm a hero. >>> The very move you are opposing so vehemently for KVM. >>> >> I don't want to fracture a working community. >> > Would you accept (or at least not NAK) a new tools/kvm/ tool that builds > tooling from grounds up, while leaving Qemu untouched? [assuming it's all > clean code, etc.] > I couldn't NAK tools/kvm any more than I could NAK a new project outside the kernel repository. IMO it would be duplicated effort, but like I mentioned before, I can't tell volunteers what to do, only recommend that they join the existing effort. > Although i have doubts about how well that would work 'against' your opinion: > such a tool would need lots of KVM-side features and a positive attitude from > you to be really useful. There's a lot of missing functionality to cover. > Functionality that can be implemented in userspace will not be accepted into kvm unless there are very good reasons why it should be. Things that belong in kvm will be more than welcome. >> Seems like perf is also split, with sysprof being developed outside the >> kernel. Will you bring sysprof into the kernel? Will every feature be >> duplicated in prof and sysprof? >> > I'd prefer if sysprof merged into perf as 'perf view' - but its maintainer > does not want that - which is perfectly OK. You spared him the flamewar, I hope. > So we are building equivalent > functionality into perf instead. > Ah, duplicating effort. Great. > Think about it like Firefox plugins: the main Firefox project picks up the > functionality of the most popular Firefox plugins all the time. Session Saver, > Tab Mix Plus, etc. were all in essence 'merged' (in functionality, not in > code) into the 'reference' Firefox project. > There's a difference between absorbing a small plugin and duplicating 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(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/ |