Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 04:37 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>>>> Certainly guests that we don't port won't be able to use this.  I doubt
>>>> we'll be able to make Windows work with this - the only performance tool I'm
>>>> familiar with on Windows is Intel's VTune, and that's proprietary.
>>>>          
>>> Dont you see the extreme irony of your wish to limit Linux kernel design
>>> decisions and features based on ... Windows and other proprietary
>>> software?
>>>        
>> Not at all.  Virtualization is a hardware compatibility game.  To see what
>> happens if you don't play it, see Xen.  Eventually they to implemented
>> hardware support even though the pv approach is so wonderful.
>>      
> That's not quite equivalent though.
>
> KVM used to be the clean, integrate-code-with-Linux virtualization approach,
> designed specifically for CPUs that can be virtualized properly. (VMX support
> first, then SVM, etc.)
>
> KVM virtualized ages-old concepts with relatively straightforward hardware
> ABIs: x86 execution, IRQ abstractions, device abstractions, etc.
>
> Now you are in essence turning that all around:
>
>   - the PMU is by no means properly virtualized nor really virtualizable by
>     direct access. There's no virtual PMU that ticks independently of the host
>     PMU.
>    

There's no guest debug registers that can be programmed independently of 
the host debug registers, but we manage somehow.  It's not perfect, but 
better than nothing.

For the common case of host-only or guest-only monitoring, things will 
work, perhaps without socketwide counters in security concious 
environments.  When both are used at the same time, something will have 
to give.

>   - the PMU hardware itself is not a well standardized piece of hardware. It's
>     very vendor dependent and very limiting.
>    

That's life.  If we force standardization by having a soft pmu, we'll be 
very limited as well.  If we don't, we reduce hardware independence 
which is a strong point of virtualization.  Clearly we need to make a 
trade-off here.

In favour of hardware dependence is that tools and users are already 
used to it.  There is also the architectural pmu that can provide a 
limited form of hardware independence.

Going pv trades off hardware dependence for software dependence.  
Suddenly only guests that you have control over can use the pmu.

> So to some degree you are playing the role of Xen in this specific affair. You
> are pushing for something that shouldnt be done in that form. You want to
> interfere with the host PMU by going via the fast&  easy short-term hack to
> just let the guest OS have the PMU, without any regard to how this impacts
> long-term feasible solutions.
>    

Maybe.  And maybe the vendors will improve virtualization support for 
the pmu, rendering the pv approach obsolete on new hardware.

> I.e. you are a bit like the guy who would have told Linus in 1994:
>
>   " Dude, why dont you use the Windows APIs? It's far more compatible and
>     that's the only way you could run any serious apps. Besides, it requires
>     no upgrade. Admittedly it's a bit messy and 16-bit but hey, that's our
>     installed base after all. "
>    

Hey, maybe we'd have significant desktop market share if he'd done this 
(though a replay of the wine history is much more likely).

But what are you suggesting?  That we make Windows a second class 
guest?  Most users run a mix of workloads, that will not go down well 
with them.  The choice is between first-class Windows support vs 
becoming a hobby hypervisor.

Let's make a kerner/user analogy again.  Would you be in favour of 
GPL-only-ing new syscalls, to give open source applications an edge over 
proprietary apps (technically known as "crap" among some)?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.