Re: [RFC] Unify KVM kernel-space and user-space code into a single project

Alexander Graf
2010-03-24T13:53:10Z

Avi Kivity wrote:
> On 03/24/2010 02:50 PM, Joerg Roedel wrote:
>>
>>> You can always provide the kernel and module paths as command line
>>> parameters. It just won't be transparently usable, but if you're using
>>> qemu from the command line, presumably you can live with that.
>>>
>> I don't want the tool for myself only. A typical perf user expects that
>> it works transparent.
>>
>
> A typical kvm user uses libvirt, so we can integrate it with that.
>
>>>> Could be easily done using notifier chains already in the kernel.
>>>> Probably implemented with much less than 100 lines of additional code.
>>>>
>>> And a userspace interface for that.
>>>
>> Not necessarily. The perf event is configured to measure systemwide kvm
>> by userspace. The kernel side of perf takes care that it stays
>> system-wide even with added vm instances. So in this case the consumer
>> for the notifier would be the perf kernel part. No userspace interface
>> required.
>>
>
> 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:

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?

Alex