On 03/16/2010 02:29 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
On 03/16/2010 01:25 PM, Ingo Molnar wrote:
I haven't followed vmchannel closely, but I think it is. vmchannel is
terminated in qemu on the host side, not in the host kernel. So perf would
need to connect to qemu.
Hm, that sounds rather messy if we want to use it to basically expose kernel
functionality in a guest/host unified way. Is the qemu process discoverable in
some secure way?
We know its pid.
How do i get a list of all 'guest instance PIDs',
Libvirt manages all qemus, but this should be implemented independently
of libvirt.
and what is the way to talk
to Qemu?
In general qemu exposes communication channels (such as the monitor) as
tcp connections, unix-domain sockets, stdio, etc. It's very flexible.
Can we trust it?
No choice, it contains the guest address space.
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.
How do you trust a userspace program's symbols? you don't. How do you
get them? they're on a well-known location.
Is there some proper tooling available to do it, or do we have to push it
through 2-3 packages to get such a useful feature done?
libvirt manages qemu processes, but I don't think this should go through
libvirt. qemu can do this directly by opening a unix domain socket in a
well-known place.
So Qemu has never run into such problems before?
( Sounds weird - i think Qemu configuration itself should be done via a
unix domain socket driven configuration protocol as well. )
That's exactly what happens. You invoke qemu with -monitor
unix:blah,server (or -qmp for a machine-readable format) and have your
management application connect to that. You can redirect guest serial
ports, console, parallel port, etc. to unix-domain or tcp sockets.
vmchannel is an extension of that mechanism.
( That is the general thought process how many cross-discipline useful
desktop/server features hit the bit bucket before having had any chance of
being vetted by users, and why Linux sucks so much when it comes to feature
integration and application usability. )
You can't solve everything in the kernel, even with a well populated tools/.
Certainly not, but this is a technical problem in the kernel's domain, so it's
a fair (and natural) expectation to be able to solve this within the kernel
project.
Someone writing perf-gui outside the kernel would have the same
problems, no?
--
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
