[lkml]   [2010]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Enhance perf to collect KVM guest os statistics from host side

    * Frank Ch. Eigler <> wrote:

    > Ingo Molnar <> 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/ 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.



     \ /
      Last update: 2010-03-16 16:55    [W:0.023 / U:66.356 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site