On Wed, Mar 24, 2010 at 02:08:17PM +0200, Avi Kivity wrote: > On 03/24/2010 01:59 PM, Joerg Roedel wrote: > You can always provide the kernel and module paths as command line > parameters. It just won't be transparently usable, but if you're using > qemu from the command line, presumably you can live with that. I don't want the tool for myself only. A typical perf user expects that it works transparent. >> Could be easily done using notifier chains already in the kernel. >> Probably implemented with much less than 100 lines of additional code. > > And a userspace interface for that. Not necessarily. The perf event is configured to measure systemwide kvm by userspace. The kernel side of perf takes care that it stays system-wide even with added vm instances. So in this case the consumer for the notifier would be the perf kernel part. No userspace interface required. > If we make an API, I'd like it to be generally useful. Thats hard to do at this point since we don't know what people will use it for. We should keep it simple in the beginning and add new features as they are requested and make sense in this context. > It's a total headache. For example, we'd need security module hooks to > determine access permissions. So far we managed to avoid that since kvm > doesn't allow you to access any information beyond what you provided it > directly. Depends on how it is designed. A filesystem approach was already mentioned. We could create /sys/kvm/ for example to expose information about virtual machines to userspace. This would not require any new security hooks. > Copying the objects is a one time cost. If you run perf for more than a > second or two, it would fetch and cache all of the data. It's really > the same problem with non-guest profiling, only magnified a bit. I don't think we can cache filesystem data of a running guest on the host. It is too hard to keep such a cache coherent. >>> Other userspaces can also provide this functionality, like they have to >>> provide disk, network, and display emulation. The kernel is not a huge >>> library. If two userspaces run in parallel what is the single instance where perf can get a list of guests from? > kvm.ko has only a small subset of the information that is used to define > a guest. The subset is not small. It contains all guest vcpus, the complete interrupt routing hardware emulation and manages event the guests memory. Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
