Re: KVM PMU virtualization

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 02/26/10 14:06, Ingo Molnar wrote:
>
> * Jes Sorensen<Jes.Sorensen@redhat.com>  wrote:
>> Well you cannot steal the PMU without collaborating with perf_event.c, but
>> thats quite feasible. Sharing the PMU between the guest and the host is very
>> costly and guarantees incorrect results in the host. Unless you completely
>> emulate the PMU by faking it and then allocating PMU counters one by one at
>> the host level. However that means trapping a lot of MSR access.
>
> It's not that many MSR accesses.

Well it's more than enough to double the number of MSRs KVM has to track
on switches.

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

If a PMU can really count stuff on another CPU, then we shouldn't allow
PMU access to any application at all. It's more than just a KVM guest vs
a KVM guest issue then, but also a thread to thread issue.

My idea was obviously not to expose host timings to a guest. Save the
counters when a guest exits, and reload them when it's restarted. Not
just when switching to another task, but also when entering KVM, to
avoid the guest seeing overhead spent within KVM.

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

As I wrote earlier, at that level we have to do it all emulated. In
this case, providing any of this to a guest seems to be a waste of time
since the interface will cost way too much in trapping back and forth
and you have contention with the very limited resources in the PMU with
just 5 counters to pick from on Core2.

The guest PMU will think it's running on top of real hardware, and
scaling/estimating numbers like the perf_event.c code does today,
except that it will be using already scaled and estimated numbers for
it's calculations. Application users will have little use for this.

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

Well either you allow access to the PMU or you don't. If you allow
direct access to the PMU counters, but not the control registers, you
have to specify the counter sizes to match that of the host, making it
impossible to really emulate core2 on a non core2 architecture etc.

Jes