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

[Avi Kivity <avi@redhat.com>]

On 05/12/2011 05:24 PM, Joerg Roedel wrote:
> >  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.
>
> The problem certainly is that with arch-pmu we add a lot of msr-exits to
> the guest-context-switch path if it uses per-task profiling. Depending
> on the workload this can very much distort the results.

Right.  The combination of per-task profiling with high context switch 
rates is problematic.

One thing we could do is paravirtualize at a lower level, introduce a 
hypercall for batch MSR reads and writes.  So we can use the existing 
PMU semantics and code, just optimize the switch.  This is similar to 
what Xen did with lazy cpu updates, and what kvm did for paravirt 
pagetable writes.

I've considered something similar for mmio - use hypercalls for ordinary 
mmio to avoid calling into the emulator - but virtio uses pio which 
isn't emulated and we don't have massive consumers of mmio (except 
perhaps hpet).

(and we can have a cpuid bit that advertises whether we recommend to use 
this feature for PMU MSRs; if/when we get hardware support, we turn it off)

-- 
error compiling committee.c: too many arguments to function