Re: KVM PMU virtualization

Avi Kivity
2010-02-26T11:53:07Z

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.