* Avi Kivity <avi@xxxxxxxxxx> wrote: > Right, this will severely limit migration domains to hosts of the same > vendor and processor generation. There is a middle ground, though, Intel > has recently moved to define an "architectural pmu" which is not model > specific. I don't know if AMD adopted it. [...] Nope. It's "architectural" the following way: Intel wont change it with future CPU models, outside of the definitions of the hw-ABI. PMUs were model specific prior that time. I'd say there's near zero chance the MSR spaces will unify. All the 'advanced' PMU features are wildly incompatible, and the gap is increasing not decreasing. > > 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 ;-) ] 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. > > That way it could also transparently integrate with tracing, probes, etc. > > It would also be wiser to first concentrate on improving Linux<->Linux > > guest/host combos before gutting the design just to fit Windows into the > > picture ... > > "gutting the design"? Yes, gutting the design of a sane instrumentation API and moving it back 10-20 years by squeezing it through non-standardized and incompatible PMU drivers. When it comes to design my main interest is the Linux<->Linux combo. 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
