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

[Avi Kivity <avi@redhat.com>]

On 03/22/2010 10:06 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> On 03/22/2010 09:20 PM, Ingo Molnar wrote:
>>      
>>> * Avi Kivity<avi@redhat.com>   wrote:
>>>
>>>        
>>>>> Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
>>>>> Anthony. There's numerous ways that this can break:
>>>>>            
>>>> I don't like it either.  We have libvirt for enumerating guests.
>>>>          
>>> Which has pretty much the same problems to the ${HOME}/.qemu/qmp/ solution,
>>> obviously.
>>>        
>> It doesn't follow.  The libvirt daemon could/should own guests from all
>> users.  I don't know if it does so now, but nothing is preventing it
>> technically.
>>      
> It's hard for me to argue against a hypothetical implementation, but all
> user-space driven solutions for resource enumeration i've seen so far had
> weaknesses that kernel-based solutions dont have.
>    

Correct.  kernel-based solutions also have issues.

>> If qemu hangs, the guest hangs a few milliseconds later.
>>      
> I think you didnt understand my point. I am talking about 'perf kvm top'
> hanging if Qemu hangs.
>    

Use non-blocking I/O, report that guest as dead.  No point in profiling 
it, it isn't making any progress.

> With a proper in-kernel enumeration the kernel would always guarantee the
> functionality, even if the vcpu does not make progress (i.e. it's "hung").
>
> With this implemented in Qemu we lose that kind of robustness guarantee.
>    

If qemu has a bug in the resource enumeration code, you can't profile 
one guest.  If the kernel has a bug in the resource enumeration code, 
the system either panics or needs to be rebooted later.

> And especially during development (when developers use instrumentation the
> most) is it important to have robust instrumentation that does not hang along
> with the Qemu process.
>    

It's nice not to have kernel oopses either.  So when code can be in 
userspace, that's where it should be.

>> If qemu fails, you lose your guest.  If libvirt forgets about a
>> guest, you can't do anything with it any more.  These are more
>> serious problems than 'perf kvm' not working. [...]
>>      
> How on earth can you justify a bug ("perf kvm top" hanging) with that there
> are other bugs as well?
>    

There's no reason for 'perf kvm top' to hang if some process is not 
responsive.  That would be a perf bug.

> Basically you are arguing the equivalent that a gdb session would be fine to
> become unresponsive if the debugged task hangs. Fortunately ptrace is
> kernel-based and it never 'hangs' if the user-space process hangs somewhere.
>    

Neither gdb nor perf should hang.

> This is an essential property of good instrumentation.
>
> So the enumeration method you suggested is a poor, sub-part solution, simple
> as that.
>    

Or, you misunderstood it.

>> [...] Qemu and libvirt have to be robust anyway, we can rely on them.  Like
>> we have to rely on init, X, sshd, and a zillion other critical tools.
>>      
> We can still profile any of those tools without the profiler breaking if the
> debugged tool breaks ...
>    

You can't profile without qemu.

>>> By your argument it would be perfectly fine to implement /proc purely via
>>> user-space, correct?
>>>        
>> I would have preferred /proc to be implemented via syscalls called directly
>> from tools, and good tools written to expose the information in it.  When
>> computers were slower 'top' would spend tons of time opening and closing all
>> those tiny files and parsing them.  Of course the kernel needs to provide
>> the information.
>>      
> (Then you'll be enjoyed to hear that perf has enabled exactly that, and that we
> are working towards that precise usecase.)
>    

Are you exporting /proc/pid data via the perf syscall?  If so, I think 
that's a good move.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.