Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> * Joerg Roedel<joro@8bytes.org>  wrote:
>
>    
>> I personally don't like a self-defined event-set as the only solution
>> because that would probably only work with linux and perf. [...]
>>      
> The 'soft-PMU' i suggested is transparent on the guest side - if you want to
> enable non-Linux and legacy-Linux.
>
> It's basically a PMU interface provided to the guest by catching the right MSR
> accesses, implemented via perf_event_create_kernel_counter()/etc. on the host
> side.
>    

That only works if the software interface is 100% lossless - we can 
recreate every single hardware configuration through the API.  Is this 
the case?

> Note that the 'soft PMU' still sucks from a design POV as there's no generic
> hw interface to the PMU. So there would have to be a 'soft AMD' and a 'soft
> Intel' PMU driver at minimum.
>    

Right, this will severely limit migration domains to hosts of the same 
vendor and processor generation.  There is a  middle ground, though, 
Intel has recently moved to define an "architectural pmu" which is not 
model specific.  I don't know if AMD adopted it.  We could offer both 
options - native host capabilities, with a loss of compatibility, and 
the architectural pmu, with loss of model specific counters.

> Far cleaner would be to expose it via hypercalls to guest OSs that are
> interested in instrumentation.

It's also slower - you can give the guest direct access to the various 
counters so no exits are taken when reading the counters (though perhaps 
many tools are only interested in the interrupts, not the counter values).

> That way it could also transparently integrate
> with tracing, probes, etc. It would also be wiser to first concentrate on
> improving Linux<->Linux guest/host combos before gutting the design just to
> fit Windows into the picture ...
>    

"gutting the design"?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.