Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 01:42 PM, Ingo Molnar wrote:
> * Jes Sorensen<Jes.Sorensen@redhat.com>  wrote:
>
>    
>> On 02/26/10 11:44, Ingo Molnar wrote:
>>      
>>> Direct access to counters is not something that is a big issue. [ Given that i
>>> sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
>>> is the biggest of performance challenges right now ;-) ]
>>>
>>> By far the biggest instrumentation issue is:
>>>
>>>   - availability
>>>   - usability
>>>   - flexibility
>>>
>>> Exposing the raw hw is a step backwards in many regards. The same way we dont
>>> want to expose chipsets to the guest to allow them to do RAS. The same way we
>>> dont want to expose most raw PCI devices to guest in general, but have all
>>> these virt driver abstractions.
>>>        
>> I have to say I disagree on that. When you run perfmon on a system, it is
>> normally to measure a specific application. You want to see accurate numbers
>> for cache misses, mul instructions or whatever else is selected.
>>      
> You can still get those. You can even enable RDPMC access and avoid VM exits.
>
> What you _cannot_ do is to 'steal' the PMU and just give it to the guest.
>    

Agreed - if both the host and guest want the pmu, the host wins.  This 
is what we do with debug registers - if both the host and guest contend 
for them, the host wins.

>> Emulating the PMU rather than using the real one, makes the numbers far less
>> useful. The most useful way to provide PMU support in a guest is to expose
>> the real PMU and let the guest OS program it.
>>      
> 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.
>    

A native API to the host will lock out 100% of the install base now, and 
a large section of any future install base.

> 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)
>    

No, stop and restart the counters on every exit/entry, so the guest 
doesn't observe any host data.

>> We can do this in a reasonable way today, if we allow to take the PMU away
>> from the host, and only let guests access it when it's in use. [...]
>>      
> You get my sure-fire NAK for that kind of crap though. Interfering with the
> host PMU and stealing it, is not a technical approach that has acceptable
> quality.
>
>    

It would be the other way round - the host would steal the pmu from the 
guest.  Later we can try to time-slice and extrapolate, though that's 
not going to be easy.

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