Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?

[Jan Kiszka]

On 2012-01-20 13:54, Daniel P. Berrange wrote:
> On Fri, Jan 20, 2012 at 01:51:20PM +0100, Jan Kiszka wrote:
>> On 2012-01-20 13:42, Daniel P. Berrange wrote:
>>> On Fri, Jan 20, 2012 at 01:00:06PM +0100, Jan Kiszka wrote:
>>>> On 2012-01-20 12:45, Daniel P. Berrange wrote:
>>>>> On Fri, Jan 20, 2012 at 12:13:48PM +0100, Jan Kiszka wrote:
>>>>>> On 2012-01-20 11:25, Daniel P. Berrange wrote:
>>>>>>> On Fri, Jan 20, 2012 at 11:22:27AM +0100, Jan Kiszka wrote:
>>>>>>>> On 2012-01-20 11:14, Marcelo Tosatti wrote:
>>>>>>>>> On Thu, Jan 19, 2012 at 07:01:44PM +0100, Jan Kiszka wrote:
>>>>>>>>>> On 2012-01-19 18:53, Marcelo Tosatti wrote:
>>>>>>>>>>>> What problems does it cause, and in which scenarios? Can't they be
>>>>>>>>>>>> fixed?
>>>>>>>>>>>
>>>>>>>>>>> If the guest compensates for lost ticks, and KVM reinjects them, 
>>>>>>>>>>> guest
>>>>>>>>>>> time advances faster then it should, to the extent where NTP fails 
>>>>>>>>>>> to
>>>>>>>>>>> correct it. This is the case with RHEL4.
>>>>>>>>>>>
>>>>>>>>>>> But for example v2.4 kernel (or Windows with non-acpi HAL) do not
>>>>>>>>>>> compensate. In that case you want KVM to reinject.
>>>>>>>>>>>
>>>>>>>>>>> I don't know of any other way to fix this.
>>>>>>>>>>
>>>>>>>>>> OK, i see. The old unsolved problem of guessing what is being 
>>>>>>>>>> executed.
>>>>>>>>>>
>>>>>>>>>> Then the next question is how and where to control this. 
>>>>>>>>>> Conceptually,
>>>>>>>>>> there should rather be a global switch say "compensate for lost 
>>>>>>>>>> ticks of
>>>>>>>>>> periodic timers: yes/no" - instead of a per-timer knob. Didn't we
>>>>>>>>>> discussed something like this before?
>>>>>>>>>
>>>>>>>>> I don't see the advantage of a global control versus per device
>>>>>>>>> control (in fact it lowers flexibility).
>>>>>>>>
>>>>>>>> Usability. Users should not have to care about individual tick-based
>>>>>>>> clocks. They care about "my OS requires lost ticks compensation, yes 
>>>>>>>> or no".
>>>>>>>
>>>>>>> FYI, at the libvirt level we model policy against individual timers, for
>>>>>>> example:
>>>>>>>
>>>>>>>   <clock offset="localtime">
>>>>>>>     <timer name="rtc" tickpolicy="catchup" track="guest"/>
>>>>>>>     <timer name="pit" tickpolicy="delay"/>
>>>>>>>   </clock>
>>>>>>
>>>>>> Are the various modes of tickpolicy fully specified somewhere?
>>>>>
>>>>> There are some (not all that great) docs here:
>>>>>
>>>>>   http://libvirt.org/formatdomain.html#elementsTime
>>>>>
>>>>> The meaning of the 4 policies are:
>>>>>
>>>>>       delay: continue to deliver at normal rate
>>>>
>>>> What does this mean? The timer stops ticking until the guest accepts its
>>>> ticks again?
>>>
>>> It means that the hypervisor will not attempt to do any compensation,
>>> so the guest will see delays in its ticks being delivered & gradually
>>> drift over time.
>>
>> Still, is the logic as I described? Or what is the difference to "discard".
> 
> With 'discard', the delayed tick will be thrown away. In 'delay', the
> delayed tick will still be injected to the guest, possibly well after
> the intended injection time though, and there will be no attempt to
> compensate by speeding up delivery of later ticks.

OK, let's see if I got it:

delay   - all lost ticks are replayed in a row once the guest accepts
          them again
catchup - lost ticks are gradually replayed at a higher frequency than
          the original tick
merge   - at most one tick is replayed once the guest accepts it again
discard - no lost ticks compensation

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux