On 2012-08-13 20:40, Michael Tokarev wrote:
> On 13.08.2012 22:18, Jan Kiszka wrote:
>> 0cdd3d1444 fixed reading back the counter load time from the kernel
>> while assuming the kernel would always update its load time on writing
>> the state. That is only true for channel 1, and so pit_get_channel_info
>> returned wrong output pin states for high counter values.
>>
>> Fix this by applying the offset also on kvm_pit_put. For this purpose,
>> we cache the clock offset in KVMPITState, only updating it on VM state
>> changes or when we write the state while the VM is stopped.
> 
> Wug.  The fix (consisting of two halves) appears to be quite messy.

I will split it up into offset caching and application to kvm_pit_put.

> Is it a (temporary) workaround or a real solution?

No, this is the real solution. It may look complex, but it is required
due to the different time bases of the in-kernel PIT and QEMU's vmclock.
We didn't care about this in qemu-kvm in the past, but upstream now
actually supports migration between in-kernel and user space models, and
it also supports the PC speaker with the in-kernel PIT enabled.

> 
> And yes, this second half fixes the reported issue with grub timekeeping,
> and should fix the seabios problem as well (so it shouldn't be necessary
> to mess with timekeeping in seabios anymore).

Thanks, great to hear!

Jan