Re: Enhance perf to support KVM

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 01:17 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>>> Do you have (or plan) any turn-key 'access to all files of the guest' kind
>>> of guest-transparent facility that could be used for such purposes?
>>>        
>> Not really.  The guest and host admins are usually different people, who
>> may, being admins, even actively hate each other.  The guest admin would
>> probably regard it as a security hole.  It's probably useful for the
>> single-host scenario, and of course for developers.
>>      
> Sounds like an exceedingly silly argument to me - the host admin is the king
> in any case.
>
> Your argument boils down to: 'dont offer transparent, turn-key solutions
> because some might object to the functionality they offer for all the wrong
> reasons'. Which does not withstand elementary scrutiny.
>    

Again, the host admin and the guest admin are different people.  What 
would the host admin do with guest files?  Why would the guest admin 
want to run any code that exposes their files?


> This is a basic usability issue, and affects many parts of the KVM universe.
>
> Really, it's by far the most fubar-ed notion of KVM. You are pushing _way_ too
> much to user-space into different modules and maintenance domains, and
> user-space forks those bits, fragments, diverts, delays and messes up basic
> features in the usual fashion.
>
> The result is a basic out-of-box virtualization experience that sucks even
> these days.
>    


> Nobody is really 'in charge' of how KVM gets delivered to the user. You
> isolated the fun kernel part for you and pushed out the boring bits to
> user-space. So if mundane things like mouse integration sucks 'hey that's a
> user-space tooling problem', if file integration sucks then 'hey, that's an
> admin problem', if it cannot be used over the network 'hey, that's an Xorg
> problem', etc. etc.
>    

What would you have me do?  Push 200K lines of device emulation code 
into the kernel?  Write an X client, toolkit, and display in the kernel 
so that mouse integration works out of the box when you install Linux 
2.6.653?

As to "nobody is in charge", that's really insulting to the people who 
are in charge of the userspace components.  Perhaps the problems that we 
see are not the same problems that you see.  It might be that direct 
access to guest files from the host is only a pressing problem for you, 
but nobody else.  If there are features that you miss, post patches, if 
you will deign to code for lowly user space.

> You basically have given up control over the quality of KVM by pushing so many
> aspects of it to user-space and letting it rot there.
>    

That's wrong on so many levels.  First, nothing is rotting in userspace, 
qemu is evolving faster than kvm is.  If I pushed it into the kernel 
then development pace would be much slower (since kernel development is 
harder), quality would be lower (less infrastructure, any bug is a host 
crash or security issue), and I personally would be totally swamped.

> Sure the design looks somewhat cleaner on paper, but if the end result is not
> helped by it then over-modularization sure can hurt ...
>    

Run 'rpm -qa' one of these days.  Modern software is modular, that's the 
only way to manage it.

> ( Note that i dont mind user-space tooling per se, as long as it sits together
>    with the kernel bits and gets developed, packaged and given to the user in
>    the same domain. )
>    

Call me when glibc, the X servers and clients, and everything else qemu 
now uses is developed, packaged, and given to the user in the same domain.

> And that's a key conceptual area were tools/perf/ differs: it's an integrated,
> turn-key solution that you can really rely on. We take responsibility for the
> full thing, no ifs and when. And if you cannot rely on your instrumentation
> tooling as a single unit you cannot use it, simple as that. (that is a key
> mistake Oprofile made a decade ago too btw.)
>    

perf is a tool written by developers for developers.  kvm is written for 
users (most of them hidden behind management interfaces).  There's no 
point at all in shipping it as part of the kernel, users don't install 
and use kernels, they install and use distributions.

> So i can see some upcoming culture friction with standing KVM principles there
> ;-)
>    

No friction at all - I don't think any kvm developer agrees with you 
(but if anyone does please speak up).

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