On 03/24/2010 04:24 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 03/24/2010 03:53 PM, Alexander Graf wrote:
Someone needs to know about the new guest to fetch its symbols. Or do
you want that part in the kernel too?
How about we add a virtio "guest file system access" device? The guest
would then expose its own file system using that device.
On the host side this would simply be a -virtioguestfs
unix:/tmp/guest.fs and you'd get a unix socket that gives you full
access to the guest file system by using commands. I envision something
like:
The idea is to use a dedicated channel over virtio-serial. If the
channel is present the file server can serve files over it.
The file server being a kernel module inside the guest? We want to be
able to serve things as early and hassle free as possible, so in this
case I agree with Ingo that a kernel module is superior.
No, just a daemon. If it's important enough we can get distributions to
package it by default, and then it will be hassle free. If "early
enough" is also so important, we can get it to start up on initrd. If
it's really critical, we can patch grub to serve the files as well.
SEND: GET /proc/version
RECV: Linux version 2.6.27.37-0.1-default (geeko@buildhost) (gcc version
4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-10-15
14:56:58 +0200
Now all we need is integration in perf to enumerate virtual machines
based on libvirt. If you want to run qemu-kvm directly, just go with
--guestfs=/tmp/guest.fs and perf could fetch all required information
automatically.
This should solve all issues while staying 100% in user space, right?
Yeah, needs a fuse filesystem to populate the host namespace (kind of
sshfs over virtio-serial).
I don't see why we need a fuse filesystem. We can of course create one
later on. But for now all you need is a user connecting to that socket.
If the perf app knows the protocol, no problem. But leave perf with
pure filesystem access and hide the details in fuse.
--
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
