|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||"Frank Ch. Eigler" <fche-AT-redhat.com> |
|| ||Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side |
|| ||Tue, 16 Mar 2010 16:52:21 +0100|
|| ||Avi Kivity <avi-AT-redhat.com>,
"Zhang, Yanmin" <yanmin_zhang-AT-linux.intel.com>,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Sheng Yang <sheng-AT-linux.intel.com>,
Marcelo Tosatti <mtosatti-AT-redhat.com>,
oerg Roedel <joro-AT-8bytes.org>,
Jes Sorensen <Jes.Sorensen-AT-redhat.com>,
Gleb Natapov <gleb-AT-redhat.com>,
Zachary Amsden <zamsden-AT-redhat.com>, ziteng.huang-AT-intel.com|
|| ||Article, Thread
* Frank Ch. Eigler <email@example.com> wrote:
> Ingo Molnar <firstname.lastname@example.org> 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
( 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.
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)