* Avi Kivity <avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
