Re: KVM PMU virtualization

[Ingo Molnar <mingo@elte.hu>]

* Avi Kivity <avi@redhat.com> wrote:

> On 02/26/2010 03:31 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@redhat.com>  wrote:
> >
> >>Or do you mean to define a new, kvm-specific pmu model and feed it off the
> >>host pmu?  In this case all the guests will need to be taught about it,
> >>which raises the compatibility problem.
> >You are missing two big things wrt. compatibility here:
> >
> >  1) The first upgrade overhead a one time overhead only.
> 
> May be one too many, for certain guests.  Of course it may be argued
> that if the guest wants performance monitoring that much, they will
> upgrade.

Yes, that can certainly be argued.

Note another logical inconsistency: you are assuming reluctance to upgrade for 
a set of users who are doing _performance analysis_.

In fact those types of users are amongst the most upgrade-happy. Often they'll 
run modern hardware and modern software. Most of the time they are developers 
themselves who try to make sure their stuff works on the latest & greatest 
hardware _and_ software.

So people running P4's trying to tune their stuff under Red Hat Linux 9 and 
trying to use the PMU uner KVM is not really a concern rooted overly deeply in 
reality.

> Certainly guests that we don't port won't be able to use this.  I doubt 
> we'll be able to make Windows work with this - the only performance tool I'm 
> familiar with on Windows is Intel's VTune, and that's proprietary.

Dont you see the extreme irony of your wish to limit Linux kernel design 
decisions and features based on ... Windows and other proprietary software?

> >  2) Once a Linux guest has upgraded, it will work in the future, with _any_
> >     future CPU - _without_ having to upgrade the guest!
> >
> >Dont you see the advantage of that? You can instrument an old system on new
> >hardware, without having to upgrade that guest for the new CPU support.
> 
> That also works for the architectural pmu, of course that's Intel
> only.  And there you don't need to upgrade the guest even once.

Besides being Intel only, it only exposes a limited sub-set of hw events. (far 
fewer than the generic ones offered by perf events)

	Ingo