Re: Enhance perf to support KVM

[Ingo Molnar <mingo@elte.hu>]

* 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.

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.

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.

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

( 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. )

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.)

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

	Ingo