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.
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.
Whenever we have a choice, we expose raw hardware (usually emulated, but
in some cases real). Raw hardware has the huge advantage of being
already supported. Write a software abstraction, and you get to (a)
write and maintain the spec (b) write drivers for all guests (c) mumble
something to users of OSes to which you haven't ported your driver (d)
explain to users that they need to install those drivers.
For networking and block, it is simply impossible to obtain good
performance without introducing a new interface, but for other stuff,
that may not be the case.
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.
Any new interface will be incompatible to all the exiting guests out
there; and unlike networking, you can't retrofit a pmu interface to an
existing guest.
When it comes to design my main interest is the Linux<->Linux combo.
My main interest is the OSes that users actually install, and those are
Windows and non-bleeding-edge Linux.
Look at guests as you do at userspace: you don't want to inflict changes
upon them.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
