Re: KVM PMU virtualization

[Ingo Molnar <mingo@elte.hu>]

* Avi Kivity <avi@redhat.com> wrote:

> On 02/26/2010 12:44 PM, Ingo Molnar wrote:
> >>>Far cleaner would be to expose it via hypercalls to guest OSs that are
> >>>interested in instrumentation.
> >>It's also slower - you can give the guest direct access to the various
> >>counters so no exits are taken when reading the counters (though perhaps
> >>many tools are only interested in the interrupts, not the counter values).
> >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 ;-) ]
> 
> Outside 4-bit vga mode, this shouldn't happen.  Can you describe
> your scenario?
> 
> >By far the biggest instrumentation issue is:
> >
> >  - availability
> >  - usability
> >  - flexibility
> >
> >Exposing the raw hw is a step backwards in many regards.
> 
> In a way, virtualization as a whole is a step backwards.  We take the nice 
> firesystem/timer/network/scheduler APIs, and expose them as raw hardware.  
> The pmu isn't any different.

Uhm, it's obviously very different. A fake NE2000 will work on both Intel and 
AMD CPUs. Same for a fake PIT. PMU drivers are fundamentally per CPU vendor 
though.

So there's no "generic hardware" to emulate.

	Ingo