On 2011-08-22 23:55, Anthony Liguori wrote: >>>> These two assessments are partly just wrong, partly fail to see the >>>> real >>>> use case. QEMU_CLOCK_HOST serves the very valid scenarios where a guest >>>> clock shall be kept synchronized on the host time, also following its >>>> jumps accordingly without stalling timers. >>> >>> The only reason we see jumps at all is because we're using >>> CLOCK_MONOTONIC or CLOCK_REALTIME. If we used CLOCK_MONOTONIC_RAW, we >>> don't see any jumps at all. >> >> CLOCK_MONOTONIC will not jump backward as well, so is perfectly fine and >> better portable. Backward jumps cannot be avoided when using a host >> system clock that is subject to follow a more accurate external source. >> But having such source for RTC emulation e.g. is a useful feature. > > I think its of limited utility. The RTC isn't universally used for time > keeping. There's also no guarantee that the guest isn't going to be > upset by this.
That's why it's configurable. On the other hand, most guests are well-prepared to deal with the RTC and the host runtime clock source not being in sync. That's why we had no bug reports after making this mode default. > > I think a better approach is to simply have a verb in qemu-ga to set/get > the guest time. That let's you implement clock adjustment without > having to worry about NTP. I'm happy to add that as part of this series. That's not that easy in legacy guests, even more when they aren't Linux. > > I don't think messing around with this stuff belongs in the QEMU clock > layer though. It's really not messing, the impact is almost minimal. Let's focus on the real big pieces first and then see what CLOCK_HOST actually contributes. That also means you should split up you patches a bit more, already for better bisectability. Jan
signature.asc
Description: OpenPGP digital signature
