Re: [PATCH] Enhance perf to collect KVM guest os statistics fromhost side

[Ingo Molnar]

* Avi Kivity <avi@xxxxxxxxxx> wrote:

> On 03/16/2010 02:29 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.

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.

 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?

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