Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

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.