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

Anthony Liguori
2010-03-22T18:28:27Z

On 03/22/2010 11:59 AM, Ingo Molnar wrote:
>
> Ok, that sounds interesting! I'd rather see some raw mechanism that 'perf kvm'
> could use instead of having to require yet another library (which generally
> dampens adoption of a tool). So i think we can work from there.
>

You can access the protocol directly if you don't want a library dependency.

> Btw., have you considered using Qemu's command name (task->comm[]) as the
> symbolic name? That way we could see the guest name in 'top' on the host - a
> nice touch.
>

qemu-system-x86_64 -name Fedora,process=qemu-Fedora

Does exactly that. We don't make this default based on the element of
least surprise. Many users expect to be able to do killall
qemu-system-x86 and if we did this by default, that wouldn't work.

>> The sockets are named based on UUID and you'll have to connect to a guest
>> and ask it for it's name. Some guests don't have names so we'll have to
>> come up with a clever way to describe a nameless VM.
>>
> I think just exposing the UUID in that lazy case would be adequate? It creates
> pressure for VM launchers to use better symbolic names.
>

Yup.

>>> I.e.:
>>>
>>> - Easy default reference to guest instances, and a way for tools to
>>> reference them symbolically as well in the multi-guest case. Preferably
>>> something trustable and kernel-provided - not some indirect information
>>> like a PID file created by libvirt-manager or so.
>>>
>> A guest is not a KVM concept. It's a qemu concept so it needs to be
>> something provided by qemu. The other caveat is that you won't see guests
>> created by libvirt because we're implementing this in terms of a default QMP
>> device and libvirt will disable defaults. This is desired behaviour.
>> libvirt wants to be in complete control and doesn't want a tool like perf
>> interacting with a guest directly.
>>
> Hm, this sucks for multiple reasons. Firstly, perf isnt a tool that
> 'interacts', it's an observation tool: just like 'top' is an observation tool.
>
> We want to enable developers to see all activities on the system - regardless
> of who started the VM or who started the process. Imagine if we had a way to
> hide tasks to hide from 'top'. It would be rather awful.
>
> Secondly, it tells us that the concept is fragile if it doesnt automatically
> enumerate all guests, regardless of how they were created.
>

Perf does interact with a guest though because it queries a guest to
read it's file system.

I understand the point you're making though. If instead of doing a pull
interface where the host queries the guest for files, if the guest
pushed a small set of files at startup which the host cached, then you
could potentially unconditionally expose a "read-only" socket that only
exposed limited information.

> Full system enumeration is generally best left to the kernel, as it can offer
> coherent access.
>

I don't see why qemu can't offer coherent access. The limitation today
is intentional and if it's overly restrictive, we can figure out a means
to change it.

Regards,

Anthony Liguori

> Ingo
>