Re: [RFC] Unify KVM kernel-space and user-space code into a single project

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Sun, 2010-03-21 at 22:20 +0100, Ingo Molnar wrote:
> * Avi Kivity <avi@redhat.com> wrote:
> 
> > > Well, for what it's worth, I rarely ever use anything else. My virtual 
> > > disks are raw so I can loop mount them easily, and I can also switch my 
> > > guest kernels from outside... without ever needing to mount those disks.
> > 
> > Curious, what do you use them for?
> > 
> > btw, if you build your kernel outside the guest, then you already have 
> > access to all its symbols, without needing anything further.
> 
> There's two errors with your argument:
> 
> 1) you are assuming that it's only about kernel symbols
> 
> Look at this 'perf report' output:
> 
> # Samples: 7127509216
> #
> # Overhead     Command                  Shared Object  Symbol
> # ........  ..........  .............................  ......
> #
>     19.14%         git  git                            [.] lookup_object
>     15.16%        perf  git                            [.] lookup_object
>      4.74%        perf  libz.so.1.2.3                  [.] inflate
>      4.52%         git  libz.so.1.2.3                  [.] inflate
>      4.21%        perf  libz.so.1.2.3                  [.] inflate_table
>      3.94%         git  libz.so.1.2.3                  [.] inflate_table
>      3.29%         git  git                            [.] find_pack_entry_one
>      3.24%         git  libz.so.1.2.3                  [.] inflate_fast
>      2.96%        perf  libz.so.1.2.3                  [.] inflate_fast
>      2.96%         git  git                            [.] decode_tree_entry
>      2.80%        perf  libc-2.11.90.so                [.] __strlen_sse42
>      2.56%         git  libc-2.11.90.so                [.] __strlen_sse42
>      1.98%        perf  libc-2.11.90.so                [.] __GI_memcpy
>      1.71%        perf  git                            [.] decode_tree_entry
>      1.53%         git  libc-2.11.90.so                [.] __GI_memcpy
>      1.48%         git  git                            [.] lookup_blob
>      1.30%         git  git                            [.] process_tree
>      1.30%        perf  git                            [.] process_tree
>      0.90%        perf  git                            [.] tree_entry
>      0.82%        perf  git                            [.] lookup_blob
>      0.78%         git  [kernel.kallsyms]              [k] kstat_irqs_cpu
> 
> kernel symbols are only a small portion of the symbols. (a single line in this 
> case)
Above example shows perf could summarize both kernel and application hot functions.
If we collect guest os statistics from host side, we can't summarize detailed guest os
application info because we couldn't get guest os's application process id from host
side. So we could only get detailed kernel info and the total utilization percent of
guest application processes.


> 
> To get to those other symbols we have to read the ELF symbols of those 
> binaries in the guest filesystem, in the post-processing/reporting phase. This 
> is both complex to do and relatively slow so we dont want to (and cannot) do 
> this at sample time from IRQ context or NMI context ...
> 
> Also, many aspects of reporting are interactive so it's done lazily or 
> on-demand. So we need ready access to the guest filesystem - for those guests 
> which decide to integrate with the host for this.