On 05/12/2011 04:11 PM, Joerg Roedel wrote:
On Thu, May 12, 2011 at 11:47:51AM +0200, Jan Kiszka wrote:
> On 2011-05-12 11:33, Joerg Roedel wrote:
> > Anyway, I thought about a paravirt-approach instead of implementing a
> > real PMU... But there are certainly good reasons for both.
>
> Paravirt is taking away the pressure from CPU vendors to do their virt
> extensions properly - and doesn't help with unmodifiable OSes.
Seriously, I think such decisions should be technical only and not
political like that. The losers of such political decisions are always
the users because they don't get useful features that are technical
possible.
I agree. But there are technical advantages to using architectural
features instead of paravirt:
- when the cpu gains support for virtualizing the architectural feature,
we transparently speed the guest up, including support for live
migrating from a deployment that emulates the feature to a deployment
that properly virtualizes the feature, and back. Usually the
virtualized support will beat the pants off any paravirtualization we can do
- following an existing spec is a lot easier to get right than doing
something from scratch
- no need to meticulously document the feature
- easier testing
- existing guest support - only need to write the host side (sometimes
the only one available to us)
We saw all that with the move from shadow paging to nested paging. We
had paravirt support which turned out to be poorly documented, had a
security issue, and would have been slower on npt. In the end we ripped
it out.
Paravirtualizing does have its advantages. For the PMU, for example, we
can have a single hypercall read and reprogram all counters, saving
*many* exits. But I think we need to start from the architectural PMU
and see exactly what the problems are, before we optimize it to death.
--
error compiling committee.c: too many arguments to function
--
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
