Re: KVM PMU virtualization

[Zachary Amsden <zamsden@redhat.com>]

On 02/26/2010 03:37 AM, Jes Sorensen wrote:
> On 02/26/10 14:31, Ingo Molnar wrote:
>> You are missing two big things wrt. compatibility here:
>>
>>   1) The first upgrade overhead a one time overhead only.
>>
>>   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 would only work if you are guaranteed to be able to emulate old
> hardware on new hardware. Not going to be feasible, so then we are in a
> real mess.
>
>> With the 'steal the PMU' messy approach the guest OS has to be 
>> upgraded to the
>> new CPU type all the time. Ad infinitum.
>
> The way the Perfmon architecture is specified by Intel, that is what we
> are stuck with. It's not going to be possible via software emulation to
> count cache misses, unless you run it in a micro architecture emulator.

Sure you can count cache misses.

Step 1. Declare KVM to possess a virtual cache hereto unseen to guest VCPUs.
Step 2. Use micro architecture rules to add to cache misses in an 
undefined micro-architecture specific way
Step 3. <censored>
Step 4.  PROFIT!

The point being, there are no rules required to follow for 
architecturally unspecified events.  Instructions issued is well defined 
architecturally, one of very few such counters, while things like cache 
strides and organization are deliberately left to the implementation.

So returning zero is a perfectly valid choice for emulating cache misses.

Zach