Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 03:06 PM, Ingo Molnar wrote:
>
>>> Firstly, an emulated PMU was only the second-tier option i suggested. By far
>>> the best approach is native API to the host regarding performance events and
>>> good guest side integration.
>>>
>>> Secondly, the PMU cannot be 'given' to the guest in the general case. Those
>>> are privileged registers. They can expose sensitive host execution details,
>>> etc. etc. So if you emulate a PMU you have to exit out of most PMU accesses
>>> anyway for a secure solution. (RDPMC can still be supported, but in close
>>> cooperation with the host)
>>>        
>> There is nothing secret in the host PMU, and it's easy to clear out the
>> counters before passing them off to the guest.
>>      
> That's wrong. On some CPUs the host PMU can be used to say sample aspects of
> another CPU, allowing statistical attacks to recover crypto keys. It can be
> used to sample memory access patterns of another node.
>
> There's a good reason PMU configuration registers are privileged and there's
> good value in only giving a certain sub-set to less privileged entities by
> default.
>    

Even if there were no security considerations, if the guest can observe 
host data in the pmu, it means the pmu is inaccurate.  We should expose 
guest data only in the guest pmu.  That's not difficult to do, you stop 
the pmu on exit and swap the counters on context switches.

>> Having an allocation scheme and sharing it with the host, is a perfectly
>> legitimate and very clean way to do it. Once it's given to the guest, the
>> host knows not to touch it until it's been released again.
>>      
> 'Full PMU' is not the granularity i find acceptable though: please do what i
> suggested, event granularity allocation and scheduling.
>
> We are rehashing the whole 'perfmon versus perf events/counters' design
> arguments again here really.
>    

Scheduling at event granularity would be a good thing.  However we need 
to be able to handle the guest using the full pmu.

Note that scheduling is only needed if both the guest and host want the 
pmu at the same time - and that should be a rare case and not the one to 
optimize for.

>>> You need to integrate it properly so that host PMU functionality still
>>> works fine. (Within hardware constraints)
>>>        
>> Well with the hardware currently available, there is no such thing as clean
>> sharing between the host and the guest. It cannot be done without messing up
>> the host measurements, which effectively renders measuring at the host side
>> useless while a guest is allowed access to the PMU.
>>      
> That's precisely my point: the guest should obviously not get raw access to
> the PMU. (except where it might matter to performance, such as RDPMC)
>    

That's doable if all counters are steerable.  IIRC some counters are 
fixed function, but I'm not certain about that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.