[Qemu-devel] [PATCH] qemu-ga-win: Document 'guest-set-time' limitation

[Qemu-devel] [PATCH] qemu-ga-win: Document 'guest-set-time' limitation

[Michal Privoznik]

The command implementation for Windows guest has this limitation. If
no time to set has been provided the documentation for the command
states that time should be read from RTC. However, on Windows bare
GetSystemTime() is used, which does not read anything from RTC rather
than return system time. Yeah, that system time which is wrong (after
stop & cont) and which we want to set.

However, there's no simple way to read RTC on windows yet [1], so
until the time somebody comes with bright implementation, we should at
least document the command implementation limitation.

1: http://msdn.microsoft.com/en-us/library/aa908981.aspx

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 qga/qapi-schema.json | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index 376e79f..91821ef 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -121,7 +121,10 @@
 # given value, then sets the Hardware Clock (RTC) to the
 # current System Time. This will make it easier for a guest
 # to resynchronize without waiting for NTP. If no @time is
-# specified, then the time to set is read from RTC.
+# specified, then the time to set is read from RTC. On Windows
+# guests there's implementation limitation that does not read the
+# time from RTC if no time has been provided. Users are advised
+# to allways pass a value for Windows guests.
 #
 # @time: #optional time of nanoseconds, relative to the Epoch
 #        of 1970-01-01 in UTC.
-- 
2.0.5

Re: [Qemu-devel] [PATCH] qemu-ga-win: Document 'guest-set-time' limitation

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

On 01/20/2015 01:30 AM, Michal Privoznik wrote:
> The command implementation for Windows guest has this limitation. If
> no time to set has been provided the documentation for the command
> states that time should be read from RTC. However, on Windows bare
> GetSystemTime() is used, which does not read anything from RTC rather
> than return system time. Yeah, that system time which is wrong (after
> stop & cont) and which we want to set.
> 
> However, there's no simple way to read RTC on windows yet [1], so
> until the time somebody comes with bright implementation, we should at
> least document the command implementation limitation.

I think it would be wiser to update the Windows guest-agent code to
explicitly fail instead of calling a useless GetSystemTime(), if we
can't meet the documented semantics of calling the function without a
timestamp.

> 
> 1: http://msdn.microsoft.com/en-us/library/aa908981.aspx
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  qga/qapi-schema.json | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
> index 376e79f..91821ef 100644
> --- a/qga/qapi-schema.json
> +++ b/qga/qapi-schema.json
> @@ -121,7 +121,10 @@
>  # given value, then sets the Hardware Clock (RTC) to the
>  # current System Time. This will make it easier for a guest
>  # to resynchronize without waiting for NTP. If no @time is
> -# specified, then the time to set is read from RTC.
> +# specified, then the time to set is read from RTC. On Windows
> +# guests there's implementation limitation that does not read the
> +# time from RTC if no time has been provided. Users are advised
> +# to allways pass a value for Windows guests.

Grammar is awkward, and there's a typo in 'allways'.  If we are okay
with just a doc change (although I argued above that we really should
have a code change), then I'd go with something more like:

In the current implementation, Windows guests are unable to read time
from the RTC, so users are advised to always pass a value.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]