On 02/26/2010 04:37 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> 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.
--
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
