Ingo Molnar <mingo@xxxxxxx> writes: > [...] >> >I.e. we really want to be able users to: >> > >> > 1) have it all working with a single guest, without having to specify 'which' >> > guest (qemu PID) to work with. That is the dominant usecase both for >> > developers and for a fair portion of testers. >> >> That's reasonable if we can get it working simply. > > IMO such ease of use is reasonable and required, full stop. > If it cannot be gotten simply then that's a bug: either in the code, or in the > design, or in the development process that led to the design. Bugs need > fixing. [...] Perhaps the fact that kvm happens to deal with an interesting application area (virtualization) is misleading here. As far as the host kernel or other host userspace is concerned, qemu is just some random unprivileged userspace program (with some *optional* /dev/kvm services that might happen to require temporary root). As such, perf trying to instrument qemu is no different than perf trying to instrument any other userspace widget. Therefore, expecting 'trusted enumeration' of instances is just as sensible as using 'trusted ps' and 'trusted /var/run/FOO.pid files'. - FChE -- 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
