Re: KVM PMU virtualization

[Zachary Amsden <zamsden@redhat.com>]

On 02/26/2010 01:42 AM, 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.
>
>    
>> 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.
>
> 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)
>
>    
>> 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.
>
> You need to integrate it properly so that host PMU functionality still works
> fine. (Within hardware constraints)
>    

I have to agree strongly with Ingo here.

If you can't reset, restore or offset the perf counters in hardware, 
then you can't expose them to the guest.  There is too much rich 
information about host state that can be derived and considered an 
information leak or covert channel, and you can't allow the guest to 
trample host PMU state.

On some architectures, to bank switch these perf counters is possible 
since you can read and write the full size counter MSRs.  However, it is 
a cumbersome task that must be done at every preemption point.  There 
are many ways to do so as lazily as possible so that overhead only 
happens in a guest which actively uses the PMU.  With careful 
bookkeeping, you can even compound the guest PMU counters back into the 
host counters if the host is using the PMU.

Sorting out the details about who to deliver the PMU exception to 
however, the host or the guest, when an overflow occurs, is a nasty, 
ugly dilemma, as is properly programming the counters so that overflow 
happens in a controlled fashion when both the host and the guest are 
attempting to use this feature.  So supporting "step ahead 13 
instructions and then give me an interrupt so I can signal my debugger" 
simultaneously and correctly in both the host and guest is a very hard 
task, perhaps untenable.

Zach