Re: KVM PMU virtualization

Avi Kivity
2010-02-26T16:03:38Z

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.