Re: KVM PMU virtualization

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 02/26/10 14:27, Ingo Molnar wrote:
>
> * Jes Sorensen<Jes.Sorensen@redhat.com>  wrote:
>> You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2,
>> whereas Nehalem and Atom are v3 if I remember correctly. [...]
>
> Of course you can emulate a good portion of it, as long as there's perf
> support on the host side for P4.

Actually P4 is pretty uninteresting in this discussion due to the lack
of VMX support, it's the same issue for Nehalem vs Core2. The problem
is the same though, we cannot tell the guest that yes P4 has this
event, but no, we are going to feed you bogus data.

> If the guest programs a cachemiss event, you program a cachemiss perf event on
> the host and feed its values to the emulated MSR state. You _dont_ program the
> raw PMU on the host side - just use the API i outlined to get struct
> perf_event.
>
> The emulation wont be perfect: not all events will count and not all events
> will be available in a P4 (and some Core2 events might not even make sense in
> a P4), but that is reality as well: often documented events dont count, and
> often non-documented events count.
>
> What matters to 99.9% of people who actually use this stuff is a few core sets
> of events - which are available in P4s and in Core2 as well. Cycles,
> instructions, branches, maybe cache-misses. Sometimes FPU stuff.

I really do not like to make guesses about how people use this stuff.
The things you and I look for as kernel hackers are often very different
than application authors look for and use. That is one thing I learned
from being expose to strange Fortran programmers at SGI.

It makes me very uncomfortable telling a guest OS that we offer features
X, Y, Z and then start lying feeding back numbers that do not match what
was requested, and there is no way to to tell the guest that.

> For Linux<->Linux the sanest, tier-1 approach would be to map sys_perf_open()
> on the guest side over to the host, transparently, via a paravirt driver.

Paravirt is a nice optimization, but is and will always be an
optimization. Fact of the matter is that the bulk of usage of
virtualization is for running distributions with slow kernel
upgrade rates, like SLES and RHEL, and other proprietary operating
systems which we have no control over. Para-virt will do little good for
either of these groups.

Cheers,
Jes