Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Anthony Liguori <aliguori <at> linux.vnet.ibm.com>
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side
Newsgroups: gmane.linux.kernel
Date: Tuesday 16th March 2010 17:34:18 UTC (over 6 years ago)
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
> 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. )
>    

Random tools (like perf) should not be able to do what you describe.  
It's a security nightmare.

If it's desirable to have /proc/kallsyms available, we can expose an 
interface in QEMU to provide that.  That can then be plumbed through 
libvirt and QMP.

Then a management tool can use libvirt or QMP to obtain that information 
and interact with the kernel appropriately.

> 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. )
>    

No way.  The guest has sensitive data and exposing it widely on the host 
is a bad thing to do.  It's a bad interface.  We can expose specific 
information about guests but only through our existing channels which 
are validated through a security infrastructure.

Ultimately, your goal is to keep perf a simple tool with little 
dependencies.  But practically speaking, if you want to add features to 
it, it's going to have to interact with other subsystems in the 
appropriate way.  That means, it's going to need to interact with 
libvirt or QMP.

If you want all applications to expose their data via synthetic file 
systems, then there's always plan9 :-)

Regards,

Anthony Liguori
 
CD: 3ms