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: Anthony Liguori on 23 Mar 2010 10:10 On 03/23/2010 04:07 AM, Avi Kivity wrote: > On 03/23/2010 12:06 AM, Anthony Liguori wrote: >>> Having qemu enumerate guests one way or another is not a good idea >>> IMO since it is focused on one guest and doesn't have a system-wide >>> entity. >> >> >> There always needs to be a system wide entity. There are two ways to >> enumerate instances from that system wide entity. You can centralize >> the creation of instances and there by maintain an list of current >> instances. You can also allow instances to be created in a >> decentralized manner and provide a standard mechanism for instances >> to register themselves with the system wide entity. >> >> IOW, it's the difference between asking libvirtd to exec(qemu) vs >> allowing a user to exec(qemu) and having qemu connect to a well known >> unix domain socket for libvirt to tell libvirtd that it exists. >> >> The later approach has a number of advantages. libvirt already >> supports both models. The former is the '/system' uri and the later >> is the '/session' uri. >> >> What I'm proposing, is to use the host file system as the system wide >> entity instead of libvirtd. libvirtd can monitor the host file >> system to participate in these activities but ultimately, moving this >> functionality out of libvirtd means that it becomes the standard >> mechanism for all qemu instances regardless of how they're launched. > > I don't like dropping sockets into the host filesystem, especially as > they won't be cleaned up on abnormal exit. I also think this breaks > our 'mechanism, not policy' policy. Someone may want to do something > weird with qemu that doesn't work well with this. The approach I've taken (which I accidentally committed and reverted) was to set this up as the default qmp device much like we have a default monitor device. A user is capable of overriding this by manually specifying a qmp device or by disabling defaults. > We could allow starting monitors from the global configuration file, > so a distribution can do this if it wants, but I don't think we should > do this ourselves by default. I've looked at making default devices globally configurable. We'll get there but I think that's orthogonal to setting up a useful default qmp device. Regards, Anthony Liguori -- 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 23 Mar 2010 12:50 On 03/23/2010 04:06 PM, Joerg Roedel wrote: > On Mon, Mar 22, 2010 at 05:06:17PM -0500, Anthony Liguori wrote: > >> There always needs to be a system wide entity. There are two ways to >> enumerate instances from that system wide entity. You can centralize >> the creation of instances and there by maintain an list of current >> instances. You can also allow instances to be created in a >> decentralized manner and provide a standard mechanism for instances to >> register themselves with the system wide entity. >> > And this system wide entity is the kvm module. It creates instances of > 'struct kvm' and destroys them. I see no problem if we just attach a > name to every instance with a good default value like kvm0, kvm1 ... or > guest0, guest1 ... User-space can override the name if it wants. The kvm > module takes care about the names being unique. > So, two users can't have a guest named MyGuest each? What about namespace support? There's a lot of work in virtualizing all kernel namespaces, you're adding to that. What about notifications when guests are added or removed? > This is very much the same as network card numbering is implemented in > the kernel. > Forcing perf to talk to qemu or even libvirt produces to much overhead > imho. Instrumentation only produces useful results with low overhead. > > It's a setup cost only. -- 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: Peter Zijlstra on 23 Mar 2010 14:30 On Tue, 2010-03-23 at 19:21 +0100, Joerg Roedel wrote: > Sidenote: I really think we should come to a conclusion about the > concept. KVM integration into perf is very useful feature to > analyze virtualization workloads. I always start my things with bare kvm, It would be very unwelcome to mandate libvirt, or for that matter running a particular userspace in the guest. -- 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 24 Mar 2010 01:00 On 03/23/2010 08:21 PM, Joerg Roedel wrote: > On Tue, Mar 23, 2010 at 06:39:58PM +0200, Avi Kivity wrote: > >> On 03/23/2010 04:06 PM, Joerg Roedel wrote: >> > >>> And this system wide entity is the kvm module. It creates instances of >>> 'struct kvm' and destroys them. I see no problem if we just attach a >>> name to every instance with a good default value like kvm0, kvm1 ... or >>> guest0, guest1 ... User-space can override the name if it wants. The kvm >>> module takes care about the names being unique. >>> >>> >> So, two users can't have a guest named MyGuest each? What about >> namespace support? There's a lot of work in virtualizing all kernel >> namespaces, you're adding to that. >> > This enumeration is a very small and non-intrusive feature. Making it > aware of namespaces is easy too. > It's easier (and safer and all the other boring bits) not to do it at all in the kernel. >> What about notifications when guests are added or removed? >> > Who would be the consumer of such notifications? A 'perf kvm list' can > live without I guess. If we need them later we can still add them. > System-wide monitoring needs to work equally well for guests started before or after the monitor. Even disregarding that, if you introduce an API, people will start using it and complaining if it's incomplete. The equivalent functionality for network interfaces is in netlink. >>> This is very much the same as network card numbering is implemented in >>> the kernel. >>> Forcing perf to talk to qemu or even libvirt produces to much overhead >>> imho. Instrumentation only produces useful results with low overhead. >>> >>> >> It's a setup cost only. >> > My statement was not limited to enumeration, I should have been more > clear about that. The guest filesystem access-channel is another > affected part. The 'perf kvm top' command will access the guest > filesystem regularly and going over qemu would be more overhead here. > Why? Also, the real cost would be accessing the filesystem, not copying data over qemu. > Providing this in the KVM module directly also has the benefit that it > would work out-of-the-box with different userspaces too. Or do we want > to limit 'perf kvm' to the libvirt-qemu-kvm software stack? > Other userspaces can also provide this functionality, like they have to provide disk, network, and display emulation. The kernel is not a huge library. > Sidenote: I really think we should come to a conclusion about the > concept. KVM integration into perf is very useful feature to > analyze virtualization workloads. > > Agreed. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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 24 Mar 2010 02:50
On 03/24/2010 07:09 AM, Andi Kleen wrote: > Joerg Roedel<joro(a)8bytes.org> writes: > >> Sidenote: I really think we should come to a conclusion about the >> concept. KVM integration into perf is very useful feature to >> analyze virtualization workloads. >> > Agreed. I especially would like to see instruction/branch tracing > working this way. This would a lot of the benefits of a simulator on > a real CPU. > If you're profiling a single guest it makes more sense to do this from inside the guest - you can profile userspace as well as the kernel. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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/ |