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.
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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
