linux-kernel - Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100316133114.GB575@elte.hu>
Date:	Tue, 16 Mar 2010 14:31:14 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	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
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
 host side


* Avi Kivity <avi@...hat.com> wrote:

> On 03/16/2010 03:08 PM, Ingo Molnar wrote:
> >
> >>>I mean, i can trust a kernel service and i can trust /proc/kallsyms.
> >>>
> >>>Can perf trust a random process claiming to be Qemu? What's the trust
> >>>mechanism here?
> >>Obviously you can't trust anything you get from a guest, no matter how you
> >>get it.
> >I'm not talking about the symbol strings and addresses, and the object
> >contents for allocation (or debuginfo). I'm talking about the basic protocol
> >of establishing which guest is which.
> 
> There is none.  So far, qemu only dealt with managing just its own
> guest, and left all multiple guest management to higher levels up
> the stack (like libvirt).
> 
> >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.

> >  2) Have some reasonable symbolic identification for guests. For example a
> >     usable approach would be to have 'perf kvm list', which would list all
> >     currently active guests:
> >
> >      $ perf kvm list
> >        [1] Fedora
> >        [2] OpenSuse
> >        [3] Windows-XP
> >        [4] Windows-7
> >
> >     And from that point on 'perf kvm -g OpenSuse record' would do the obvious
> >     thing. Users will be able to just use the 'OpenSuse' symbolic name for
> >     that guest, even if the guest got restarted and switched its main PID.
> >
> > Any such facility needs trusted enumeration and a protocol where i can 
> > trust that the information i got is authorative. (I.e. 'OpenSuse' truly 
> > matches to the OpenSuse session - not to some local user starting up a 
> > Qemu instance that claims to be 'OpenSuse'.)
> >
> > Is such a scheme possible/available? I suspect all the KVM configuration 
> > tools (i havent used them in some time - gui and command-line tools alike) 
> > use similar methods to ease guest management?
> 
> You can do that through libvirt, but that only works for guests started 
> through libvirt.  libvirt provides command-line tools to list and manage 
> guests (for example autostarting them on startup), and tools built on top of 
> libvirt can manage guests graphically.
> 
> Looks like we have a layer inversion here.  Maybe we need a plugin system - 
> libvirt drops a .so into perf that teaches it how to list guests and get 
> their symbols.

Is libvirt used to start up all KVM guests? If not, if it's only used on some 
distros while other distros have other solutions then there's apparently no 
good way to get to such information, and the kernel bits of KVM do not provide 
it.

To the user (and to me) this looks like a KVM bug / missing feature. (and the 
user doesnt care where the blame is) If that is true then apparently the 
current KVM design has no technically actionable solution for certain 
categories of features!

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