Re: KVM PMU virtualization

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2010-02-26 at 14:51 +0100, Jes Sorensen wrote:
> 
> > Furthermore, when KVM doesn't virtualize the physical system topology,
> > some PMU features cannot even be sanely used from a vcpu.
> 
> That is definitely an issue, and there is nothing we can really do about
> that. Having two guests running in parallel under KVM means that they
> are going to see more cache misses than they would if they ran barebone
> on the hardware.
> 
> However even with all of this, we have to keep in mind who is going to
> use the performance monitoring in a guest. It is going to be application
> writers, mostly people writing analytical/scientific applications. They
> rarely have control over the OS they are running on, but are given
> systems and told to work on what they are given. Driver upgrades and
> things like that don't come quickly. However they also tend to
> understand limitations like these and will be able to still benefit from
> perf on a system like that.

What I meant was things like memory controller bound counters, intel
uncore and amd northbridge, without knowing what node the vcpu got
scheduled to there is no way they can program the raw hardware in a
meaningful way, amd nb in particular is interesting in that you could
choose not to offer the intel uncore msrs, but the amd nb are shadowed
over the generic pmcs, so you have no way to filter those out.

Same goes for stuff like the intel ANY flag, LBR filter control and
similar muck, a vcpu can't make use of those things in a meaningful
manner.

Also, intel debugstore things requires a host linear address, again, not
something a vcpu can easily provide (although that might be worked
around with an msr trap, but that still limits you to 1 page data sizes,
not a limitation all software will respect).

> All that said, what we really want is for Intel+AMD to come up with
> proper hw PMU virtualization support that makes it easy to rotate the
> full PMU in and out for a guest. Then this whole discussion will become
> a non issue.

As it stands there simply are a number of PMU features that defy being
virtualized, simply because the virt stuff doesn't do system topology.
So even if they were to support a virtualized pmu, it would likely be a
different beast than the native hardware is, and it will be several
hardware models in the future, coming up with a paravirt interface and
getting !linux hosts to adapt and !linux guests to use is probably as
'easy'.