Re: KVM PMU virtualization

Avi Kivity
2010-02-26T11:17:15Z

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.