Re: KVM PMU virtualization

[Joerg Roedel <joro@8bytes.org>]

On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote:
>  - A paravirt event driver is more compatible and more transparent in the long 
>    run: it allows hardware upgrade and upgraded PMU functionality (for Linux) 
>    without having to upgrade the guest OS. Via that a guest OS could even be
>    live-migrated to a different PMU, without noticing anything about it.
> 
>    In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS 
>    always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state 
>    cannot be live-migrated. (save/restore doesnt help)

I agree with your arguments, having this soft-pmu for the guest has some
advantages over raw pmu access. It has a lot of advantages if the guest
migrated between hosts with different hardware.

But I still think we should have both, a soft-pmu and a pmu-emulation
(which is a more accurate term than 'raw guest pmu access') that looks
to the guest as a real hardware pmu would look like.  On a linux host
that is dedicated to executing virtual kvm machines there is little
point in sharing the pmu between guest and host because the host will
probably never use it.

This pmu-emulation will still use the perf-infrastructure for scheduling
the pmu registers, programming the pmu registers and things like that.
This could be used for example to emulate 48bit counters for the guest
even if the host only supports 32 bit counters. We even need the perf
infrastructure when we need to reinject pmu events into the guest.

>  - It's more secure: the host can have a finegrained policy about what kinds of
>    events it exposes to the guest. It might chose to only expose software 
>    events for example.

What do you mean by software events?


	Joerg