* Frank Ch. Eigler <fche@xxxxxxxxxx> wrote: > > 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'. You are quite mistaken: KVM isnt really a 'random unprivileged application' in this context, it is clearly an extension of system/kernel services. ( Which can be seen from the simple fact that what started the discussion was 'how do we get /proc/kallsyms from the guest'. I.e. an extension of the existing host-space /proc/kallsyms was desired. ) In that sense the most natural 'extension' would be the solution i mentioned a week or two ago: to have a (read only) mount of all guest filesystems, plus a channel for profiling/tracing data. That would make symbol parsing easier and it's what extends the existing 'host space' abstraction in the most natural way. ( It doesnt even have to be done via the kernel - Qemu could implement that via FUSE for example. ) As a second best option a 'symbol server' might be used too. Thanks, Ingo -- 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
