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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1269241164.2078.4.camel@ymzhang.sh.intel.com>
Date:	Mon, 22 Mar 2010 14:59:24 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>,
	Antoine Martin <antoine@...afix.co.uk>,
	Olivier Galibert <galibert@...ox.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

On Sun, 2010-03-21 at 22:20 +0100, Ingo Molnar wrote:
> * Avi Kivity <avi@...hat.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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/