Re: [PATCH v1 0/5] KVM in-guest performance monitoring

[Avi Kivity <avi@redhat.com>]

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