qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Time resync by qemu-ga


From: mdroth
Subject: Re: [Qemu-devel] [RFC] Time resync by qemu-ga
Date: Wed, 2 Jan 2013 16:53:10 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Dec 28, 2012 at 12:29:15AM +0800, Lei Li wrote:
> Hi guys,
> 
> I am working on the time drift issue as background info here.
> 
> http://mid.gmane.org/address@hidden
> 
> As Anthony proposed, one part of the solutions is that we want
> to add a qemu-ga command to resync the guest clock by reading the
> wallclock time when the tick overflow the limit to the number
> of missed ticks.
> 
> When I implement on the qemu-ga side, I got some problems and
> I'd like to send this RFC out and ask for suggestions and comments
> to make sure I am in the right direction before I send out the code.
> 
> The proposed interface for qemu-ga command as link here:
> 
> http://wiki.qemu.org/Features/GuestAgent/UsefulCommands
> 
> This maybe easier to implement, but I think this interface may
> have problem, like the delta issue. So I am trying to implement
> it like below.
> 
> The interface looks like:
> 
> { 'command': 'guest-resync-time' }
> 
> The way it works:
> 
> When calling this command in the host, qemu-ga would try to
> get the wallclock time in the host by handling guest->host
> commands, and then write this time to the guest hardware.
> 
> But looks like we don't have the way to get host information
> now, since qemu-ga just handle host->guest commands (Correct
> me if I am wrong). To solve this, we should add support to
> get host information by handling guest->host commands by qemu-ga
> first.
> 
> Please correct me if I am wrong. And suggestions and comments
> are very appreciated, specifically the way to handle quest->host
> commands by qemu-ga since I am still struggling with this.

I don't think the guest actually needs to talk to the host here, it's
okay to punt some of the work to the host/management. Since we just
need to be able to set the guest time in cases where NTP is disabled, or
the guest is too far behind for the NTP clients to adjust the time (Windows
has a configurable threshold for instance), all we really need to
know to do this is the host time in UTC (which is presumably correct), and
the guest offset from that (timezone basically: UTC, UTC+4, etc.).

So to set the time we'd just need a guest-set-time interface as proposed in
the wiki, and to know what to set it to we would probably need something
like:

{'execute':'guest-get-time'}
{'seconds': 1343862720, 'nanoseconds': 123000000, 'utc-offset': -6}

the seconds/nanoseconds in this case is mostly for completeness, the
utc-offset is all we really need to translate the host time into the
appropriate guest time for the set-time command.

> 
> Thanks!
> 
> -- 
> Lei
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]