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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux