Re: [RFC] Paravirt timer for KVM

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Hollis Blanchard wrote:
> On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote:
>   
>> Hollis Blanchard wrote:
>>     
>>> On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
>>>   
>>>       
>>>> +config KVM_CLOCK
>>>> +       bool "KVM paravirtualized clock"
>>>> +       depends on PARAVIRT && GENERIC_CLOCKEVENTS
>>>> +       help
>>>> +         Turning on this option will allow you to run a paravirtualized clock
>>>> +         when running over the KVM hypervisor. Instead of relying on a PIT
>>>> +         (or probably other) emulation by the underlying device model, the host
>>>> +         provides the guest with timing infrastructure, as time of day, and
>>>> +         timer expiration.
>>>>     
>>>>         
>>> I must have missed earlier discussion on this topic, so I'm left
>>> wondering... what's the point? What's wrong with PIT (et al) emulation?
>>>   
>>>       
>> There are three separate reasons, that I know of, to have a PV timer.
>>
>> 1) the PIT is periodic.  a PV timer can offer a one shot timer which 
>> enables dynticks.
>>     
>
> Obviously people have figured out how to do dynticks on real x86
> hardware, so I don't accept this reason. :)
>   

Using more advanced timers like the HPET.

>> 2) the TSC would have to be used as a clocksource.  You don't know the 
>> frequency which is the first problem with using the TSC but some systems 
>> have a TSC that changes frequencies.  A PV time source gives you more 
>> stable clocksource (although as in glommer's patch, when the TSC can be 
>> used, it's better to use it).
>>     
>
> As I understand it, the TSC is based on CPU frequency, which changes
> with power management. Architectural bug.
>
> However, PV time still doesn't help here:
>       * The TSC is _user_ accessible, so PV time support in the guest
>         kernel doesn't solve the problem.
>       * It looks like external agents can perform out-of-kernel
>         frequency scaling on x86 (at least I see options for it on IBM
>         blades). So there must already exist some mechanism for a kernel
>         to be informed that the TSC frequency has been changed.
>   

I don't know if that is scaled transparently to the host OS or just at 
boot time.  Keep in mind too, modern Intel processors have fixed 
frequency TSCs so it's possible that that's only an option for those 
processors.

Regards,

Anthony Liguori

>> 3) a PV clock can support stolen time calculation which there really 
>> isn't a concept of with emulation.
>>     
>
> This is true, and I know other platforms support this functionality. I
> think it's mostly useful for process time accounting. Is that actually
> supported in this patch?
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/