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
Attachment:
signature.asc
Description: OpenPGP digital signature