Re: Performance monitoring units and KVM

Andi Kleen
2008-01-30T18:26:25Z

> Balaji Rao wrote:
>> On Wednesday 30 January 2008 11:11:51 pm Avi Kivity wrote:
>>
>>> Markus Armbruster wrote:
>>>
>>>> System-wide profiling of the *virtual* machine is related to profiling
>>>> just a process. That's hard. I guess building on Perfmon2 would make
>>>> sense there, but as long as it's out of tree... Can we wait for it?
>>>> If not, what then?
>>>>
>>> Give the guest access to the real PMU. Save them on every exit
>>> (switching profiling off), and restore them on every entry (switching
>>> profiling on). The only problem with this is that it is very cpu model
>>> dependent, losing the hardware independence that virtual machines have.
>>> If you are satisfied with the architectural performance counters, then
>>> we even have hardware independence.
>>>
>> But don't the architectural performance counters vary between Intel and AMD
>> cpus ? AFAIK, they do. And, this would pose problems during migration between
>> Intel and AMD hosts.
>>
>>
>
> The also vary between Intel hosts of different models, and likely
> different AMD hosts as well. The PMU is not architectural (or, in other
> words, model specific).

Intel has an architectural PMU now, but it only works
on relatively new CPUs and not on AMD.

>> I am not sure how important is it to support migration between Intel and AMD
>> hosts. If it were not that important, then IMO we could go ahead with exposing
>> the real PMU. Maybe we could warn users against running profilers in the guest
>> if they intend it to to be Intel<->AMD migrateable ?
>>
>
> We can give the user the option to expose only the architectural PMU
> (which is quite limited) and have cross-model migration, or to expose
> the full PMU and lose hardware independence.

There is no really an architectural PMU if you consider
boxes beyond relatively new Intel CPUs (which got one)

But on the other hand in my experience most PMU users use
relatively simple few counters (e.g. 90+% likely the local
variant of CPU_CYCLES_NONHALTED) so it would be in theory
possible to translate those by traps from a different CPU's
format in the monitor into the local MSR.

The only trouble is that is no architectural way to tell
the guest "i support only counter X Y Z" and also no
nice way to reject a particular counter except for just
not ticking.

And trapping these MSR writes might be too slow for some
applications.

Still I suspect just emulating cycles non halting would
be a decent 95+% solution.

-Andi