Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 02:38 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> On 02/26/2010 02:07 PM, Ingo Molnar wrote:
>>      
>>> * Avi Kivity<avi@redhat.com>   wrote:
>>>
>>>        
>>>> A native API to the host will lock out 100% of the install base now, and a
>>>> large section of any future install base.
>>>>          
>>> ... which is why i suggested the soft-PMU approach.
>>>        
>> Not sure I understand it completely.
>>
>> Do you mean to take the model specific host pmu events, and expose them to
>> the guest via trap'n'emulate?  In that case we may as well assign the host
>> pmu to the guest if the host isn't using it, and avoid the traps.
>>      
> You are making the incorrect assumption that the emulated PMU uses up all host
> PMU resources ...
>    

Well, in the general case, it may?  If it doesn't, the host may use 
them.  We do a similar thing with debug breakpoints.

Sharing the pmu will mean trapping control msr writes at least, though.

>> Do you mean to choose some older pmu and emulate it using whatever pmu model
>> the host has?  I haven't checked, but aren't there mutually exclusive events
>> in every model pair?  The closest thing would be the architectural pmu
>> thing.
>>      
> Yes, something like Core2 with 2 generic events.
>
> That would leave 2 extra generic events on Nehalem and better. (which is
> really the target CPU type for any new feature we are talking about right now.
> Plus performance analysis tends to skew towards more modern CPU types as
> well.)
>    

Can you emulate the Core 2 pmu on, say, a P4?  Those P4s have very 
different instruction caches so I imagine the events are very different 
as well.

Agree about favouring modern processors.

> Plus the emulation can be smart about it and only use up a given number. Most
> guest OSs dont use the full PMU - they use a single counter.
>    

But you have to expose all of the counters, no?  Unless you go with a 
kvm-specific pmu as described below.

> Ideally for Linux<->Linux there would be a PMU paravirt driver that allocates
> events on an as-needed basis.
>    

Or we could watch the control register and see how the guest programs 
it, provided it doesn't do that a lot.

>> Or do you mean to define a new, kvm-specific pmu model and feed it off the
>> host pmu?  In this case all the guests will need to be taught about it,
>> which raises the compatibility problem.
>>
>>      
>>> And note that _any_ solution we offer locks out 100% of the installed base
>>> right now, as no solution is in the kernel yet. The only question is what
>>> kind of upgrade effort is needed for users to make use of the feature.
>>>        
>> I meant the guest installed base.  Hosts can be upgraded transparently to
>> the guests (not even a shutdown/reboot).
>>      
> The irony: this time guest-transparent solutions that need no configuration
> are good? ;-)
>
> The very same argument holds for the file server thing: a guest transparent
> solution is easier wrt. the upgrade path.
>    

If we add pmu support, guests can begin to use if immediately.  If we 
add the file server support, guests need to install drivers before they 
can use it, while guest admins have no motivation to do so (it helps the 
host, not the guest).

Is something wrong with just using sshfs?  Seems a lot less hassle to me.

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