Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?

[Jan Kiszka <jan.kiszka@siemens.com>]

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".

Jan

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