[Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Dan Kenigsberg]

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

Real PC lets its user set the real-time-clock and store it on CMOS,
which advances the clock even when the PC is offline.

These patches will allow doing the same with VM:
- Before shutting a VM down, use the monitor's info timeoffset to see
  how much (in seconds) does the rtc differ from the host clock.
- Store this offset somewhere.
- Use it next time with -startdate now+offset.

Please tell me what do you think of it.

Dan.

[-- Attachment #2: 0001-when-specifying-localtime-startdate-is-expressed.patch --]
[-- Type: text/plain, Size: 2595 bytes --]

>From 7b5505ef931fb900d365d23026698a6865fd3e83 Mon Sep 17 00:00:00 2001
From: Dan Kenigsberg <danken@qumranet.com>
Date: Sun, 27 Apr 2008 13:09:17 +0300
Subject: [PATCH] when specifying -localtime, -startdate is expressed as local time.

---
 vl.c |   30 +++++++++++++-----------------
 1 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/vl.c b/vl.c
index 78486cf..7f22152 100644
--- a/vl.c
+++ b/vl.c
@@ -181,7 +181,7 @@ int nb_nics;
 NICInfo nd_table[MAX_NICS];
 int vm_running;
 static int rtc_utc = 1;
-static int rtc_date_offset = -1; /* -1 means no change */
+static int rtc_date_offset = 0; /* 0 means no change */
 int cirrus_vga_enabled = 1;
 int vmsvga_enabled = 0;
 #ifdef TARGET_SPARC
@@ -1574,15 +1574,11 @@ void qemu_get_timedate(struct tm *tm, int offset)
 
     time(&ti);
     ti += offset;
-    if (rtc_date_offset == -1) {
-        if (rtc_utc)
-            ret = gmtime(&ti);
-        else
-            ret = localtime(&ti);
-    } else {
-        ti -= rtc_date_offset;
+    ti -= rtc_date_offset;
+    if (rtc_utc)
         ret = gmtime(&ti);
-    }
+    else
+        ret = localtime(&ti);
 
     memcpy(tm, ret, sizeof(struct tm));
 }
@@ -1591,13 +1587,10 @@ int qemu_timedate_diff(struct tm *tm)
 {
     time_t seconds;
 
-    if (rtc_date_offset == -1)
-        if (rtc_utc)
-            seconds = mktimegm(tm);
-        else
-            seconds = mktime(tm);
-    else
+    if (rtc_utc)
         seconds = mktimegm(tm) + rtc_date_offset;
+    else
+        seconds = mktime(tm) + rtc_date_offset;
 
     return seconds - time(NULL);
 }
@@ -8785,7 +8778,7 @@ int main(int argc, char **argv)
                     struct tm tm;
                     time_t rtc_start_date;
                     if (!strcmp(optarg, "now")) {
-                        rtc_date_offset = -1;
+                        rtc_date_offset = 0;
                     } else {
                         if (sscanf(optarg, "%d-%d-%dT%d:%d:%d",
                                &tm.tm_year,
@@ -8807,7 +8800,10 @@ int main(int argc, char **argv)
                         }
                         tm.tm_year -= 1900;
                         tm.tm_mon--;
-                        rtc_start_date = mktimegm(&tm);
+                        if (rtc_utc)
+                            rtc_start_date = mktimegm(&tm);
+                        else
+                            rtc_start_date = mktime(&tm);
                         if (rtc_start_date == -1) {
                         date_fail:
                             fprintf(stderr, "Invalid date format. Valid format are:\n"
-- 
1.5.4.5


[-- Attachment #3: 0002-specify-startdate-offset-from-the-command-line.patch --]
[-- Type: text/plain, Size: 1905 bytes --]

>From 6fb0e482a932ef77683a54cbf19681b22fe31d34 Mon Sep 17 00:00:00 2001
From: Dan Kenigsberg <danken@qumranet.com>
Date: Sun, 27 Apr 2008 13:49:47 +0300
Subject: [PATCH] specify startdate offset from the command line

---
 vl.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index 7f22152..34d8e68 100644
--- a/vl.c
+++ b/vl.c
@@ -8777,7 +8777,19 @@ int main(int argc, char **argv)
                 {
                     struct tm tm;
                     time_t rtc_start_date;
-                    if (!strcmp(optarg, "now")) {
+                    char sign;
+                    if (sscanf(optarg, "now%c%lu", 
+                                        &sign, &rtc_date_offset) == 2) {
+                        switch (sign) {
+                            case '+':
+                                rtc_date_offset = -rtc_date_offset;
+                                break;
+                            case '-':
+                                break;
+                            default:
+                                goto date_fail;
+                        }
+                    } else if (!strcmp(optarg, "now")) {
                         rtc_date_offset = 0;
                     } else {
                         if (sscanf(optarg, "%d-%d-%dT%d:%d:%d",
@@ -8807,7 +8819,7 @@ int main(int argc, char **argv)
                         if (rtc_start_date == -1) {
                         date_fail:
                             fprintf(stderr, "Invalid date format. Valid format are:\n"
-                                    "'now' or '2006-06-17T16:01:21' or '2006-06-17'\n");
+                                    "'now' or 'now{+-}offset' or '2006-06-17T16:01:21' or '2006-06-17'\n");
                             exit(1);
                         }
                         rtc_date_offset = time(NULL) - rtc_start_date;
-- 
1.5.4.5


[-- Attachment #4: 0003-read-current-rtc-offset-guest-vs.-host-from-the-mo.patch --]
[-- Type: text/plain, Size: 2793 bytes --]

>From d8f029819dcf2bf266e93661cf3c2f1503504835 Mon Sep 17 00:00:00 2001
From: Dan Kenigsberg <danken@qumranet.com>
Date: Sun, 27 Apr 2008 18:10:00 +0300
Subject: [PATCH] read current rtc offset (guest vs. host) from the monitor.
 this allows management software to notice rtc changes from the guest.

---
 console.h        |    5 +++++
 hw/mc146818rtc.c |    5 +++++
 hw/pc.c          |    6 ++++++
 monitor.c        |    4 ++++
 vl.c             |   12 ++++++++++++
 5 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/console.h b/console.h
index c7f29f5..44d0dad 100644
--- a/console.h
+++ b/console.h
@@ -149,6 +149,11 @@ int vnc_display_open(DisplayState *ds, const char *display);
 int vnc_display_password(DisplayState *ds, const char *password);
 void do_info_vnc(void);
 
+#if defined(TARGET_I386)
+/* pc.c */
+void do_info_timeoffset(void);
+#endif
+
 /* curses.c */
 void curses_display_init(DisplayState *ds, int full_screen);
 
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 30bb044..3294363 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -487,6 +487,11 @@ RTCState *rtc_init(int base, qemu_irq irq)
     return s;
 }
 
+int rtc_get_timeoffset(RTCState *s)
+{
+    return qemu_timedate_offset(&s->current_tm);
+}
+
 /* Memory mapped interface */
 static uint32_t cmos_mm_readb (void *opaque, target_phys_addr_t addr)
 {
diff --git a/hw/pc.c b/hw/pc.c
index 44a021b..ff440c7 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -50,6 +50,12 @@ static PITState *pit;
 static IOAPICState *ioapic;
 static PCIDevice *i440fx_state;
 
+void do_info_timeoffset(void)
+{
+    int rtc_get_timeoffset(RTCState *s);
+    term_printf("now%+d\n", rtc_get_timeoffset(rtc_state));
+}
+
 static void ioport80_write(void *opaque, uint32_t addr, uint32_t data)
 {
 }
diff --git a/monitor.c b/monitor.c
index 574973d..76817e1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1406,6 +1406,10 @@ static term_cmd_t info_cmds[] = {
       "", "show which guest mouse is receiving events" },
     { "vnc", "", do_info_vnc,
       "", "show the vnc server status"},
+#if defined(TARGET_I386)
+    { "timeoffset", "", do_info_timeoffset,
+      "", "show how much the VM real time clock differ from host time" },
+#endif
     { "name", "", do_info_name,
       "", "show the current VM name" },
 #if defined(TARGET_PPC)
diff --git a/vl.c b/vl.c
index 34d8e68..c3c575c 100644
--- a/vl.c
+++ b/vl.c
@@ -1595,6 +1595,18 @@ int qemu_timedate_diff(struct tm *tm)
     return seconds - time(NULL);
 }
 
+int qemu_timedate_offset(struct tm *tm)
+{
+    time_t seconds;
+
+    if (rtc_utc)
+        seconds = mktimegm(tm);
+    else
+        seconds = mktime(tm);
+
+    return seconds - time(NULL);
+}
+
 /***********************************************************/
 /* character device */
 
-- 
1.5.4.5

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Avi Kivity]

Dan Kenigsberg wrote:
> Real PC lets its user set the real-time-clock and store it on CMOS,
> which advances the clock even when the PC is offline.
>
> These patches will allow doing the same with VM:
> - Before shutting a VM down, use the monitor's info timeoffset to see
>   how much (in seconds) does the rtc differ from the host clock.
> - Store this offset somewhere.
> - Use it next time with -startdate now+offset.
>
> Please tell me what do you think of it.
>   

How about (additionally) modifying -startdate to accept an offset directly?

   qemu -startdate +0300 ...

Useful for those Windows VMs which have localtime in cmos.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Dan Kenigsberg]

On Sun, Apr 27, 2008 at 07:39:42PM +0300, Avi Kivity wrote:
> Dan Kenigsberg wrote:
>> Real PC lets its user set the real-time-clock and store it on CMOS,
>> which advances the clock even when the PC is offline.
>>
>> These patches will allow doing the same with VM:
>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>   how much (in seconds) does the rtc differ from the host clock.
>> - Store this offset somewhere.
>> - Use it next time with -startdate now+offset.
>>
>> Please tell me what do you think of it.
>>   
>
> How about (additionally) modifying -startdate to accept an offset directly?
>
>   qemu -startdate +0300 ...
>
> Useful for those Windows VMs which have localtime in cmos.

I'm missing somthing: in what way is it different than the suggested

    qemu -startdate now+offset ?

Only in allowing to specify the offset in hours/minutes?

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Avi Kivity]

Dan Kenigsberg wrote:
> On Sun, Apr 27, 2008 at 07:39:42PM +0300, Avi Kivity wrote:
>   
>> Dan Kenigsberg wrote:
>>     
>>> Real PC lets its user set the real-time-clock and store it on CMOS,
>>> which advances the clock even when the PC is offline.
>>>
>>> These patches will allow doing the same with VM:
>>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>>   how much (in seconds) does the rtc differ from the host clock.
>>> - Store this offset somewhere.
>>> - Use it next time with -startdate now+offset.
>>>
>>> Please tell me what do you think of it.
>>>   
>>>       
>> How about (additionally) modifying -startdate to accept an offset directly?
>>
>>   qemu -startdate +0300 ...
>>
>> Useful for those Windows VMs which have localtime in cmos.
>>     
>
> I'm missing somthing: in what way is it different than the suggested
>
>     qemu -startdate now+offset ?
>
> Only in allowing to specify the offset in hours/minutes?
>
>   

The difference is that I didn't read your patch, only the description.

I assumed you meant the user calculates now + offset and enters the 
result as the argument to -startdate, but you're not doing that.  Sorry 
for the noise.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Sergey Bychkov]

> Dan Kenigsberg wrote:
> How about (additionally) modifying -startdate to accept an offset 
> directly?
>
>   qemu -startdate +0300 ...
>
> Useful for those Windows VMs which have localtime in cmos.

For that users option -localtime was invented :)

PS But idea is good

Sergey Bychkow
ICQ: 21014758
FTN: 2:450/118.55 

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Anthony Liguori]

Dan Kenigsberg wrote:
> Real PC lets its user set the real-time-clock and store it on CMOS,
> which advances the clock even when the PC is offline.
>
> These patches will allow doing the same with VM:
> - Before shutting a VM down, use the monitor's info timeoffset to see
>   how much (in seconds) does the rtc differ from the host clock.
> - Store this offset somewhere.
> - Use it next time with -startdate now+offset.
>
> Please tell me what do you think of it.
>   

I think a more general mechanism that stored nvram in a file would be 
interesting.  Something like like -nvram file.ram.  This also allows a 
guest to determine it's initial boot device and for that setting to persist.

Regards,

Anthony Liguori

> Dan.
>   

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Dan Kenigsberg]

On Sun, Apr 27, 2008 at 11:58:17AM -0500, Anthony Liguori wrote:
> Dan Kenigsberg wrote:
>> Real PC lets its user set the real-time-clock and store it on CMOS,
>> which advances the clock even when the PC is offline.
>>
>> These patches will allow doing the same with VM:
>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>   how much (in seconds) does the rtc differ from the host clock.
>> - Store this offset somewhere.
>> - Use it next time with -startdate now+offset.
>>
>> Please tell me what do you think of it.
>>   
>
> I think a more general mechanism that stored nvram in a file would be 
> interesting.  Something like like -nvram file.ram.  This also allows a 
> guest to determine it's initial boot device and for that setting to 
> persist.
>

Sounds not dissimilar to migration-to-file of all cmos bits and pieces
of all supported architectures, doesn't it? I hope this general
mechanism does not block, in your opnion, the suggested specific solution.

Dan.

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Dan Kenigsberg]

On Sun, Apr 27, 2008 at 11:58:17AM -0500, Anthony Liguori wrote:
> Dan Kenigsberg wrote:
>> Real PC lets its user set the real-time-clock and store it on CMOS,
>> which advances the clock even when the PC is offline.
>>
>> These patches will allow doing the same with VM:
>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>   how much (in seconds) does the rtc differ from the host clock.
>> - Store this offset somewhere.
>> - Use it next time with -startdate now+offset.
>>
>> Please tell me what do you think of it.
>>   
>
> I think a more general mechanism that stored nvram in a file would be 
> interesting.  Something like like -nvram file.ram.  This also allows a 
> guest to determine it's initial boot device and for that setting to 
> persist.

I'm not sure I understood what you suggest here.

Plainly storing the rtc state on file is not enough, as unlike with real
hardware, nothing will advance it when the power is off.

Do you suggest to set up a mechanism (in parallel to savevm/loadvm)
where each device with non-volatile memory could register to? Probably,
in most devices the SaveStateHandler could play the role of
SaveNVStateHandler, but some would have to do something else. This would
make the file.ram different than a memory dump.

Regards,

    Dan

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Anthony Liguori]

Dan Kenigsberg wrote:
> On Sun, Apr 27, 2008 at 11:58:17AM -0500, Anthony Liguori wrote:
>   
>> Dan Kenigsberg wrote:
>>     
>>> Real PC lets its user set the real-time-clock and store it on CMOS,
>>> which advances the clock even when the PC is offline.
>>>
>>> These patches will allow doing the same with VM:
>>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>>   how much (in seconds) does the rtc differ from the host clock.
>>> - Store this offset somewhere.
>>> - Use it next time with -startdate now+offset.
>>>
>>> Please tell me what do you think of it.
>>>   
>>>       
>> I think a more general mechanism that stored nvram in a file would be 
>> interesting.  Something like like -nvram file.ram.  This also allows a 
>> guest to determine it's initial boot device and for that setting to 
>> persist.
>>     
>
> I'm not sure I understood what you suggest here.
>
> Plainly storing the rtc state on file is not enough, as unlike with real
> hardware, nothing will advance it when the power is off.
>   

If you made the CMOS non-volatile, what you would store in the CMOS is 
the clock-offset, not the actual clock time.  Then when the VM started 
up again, it would Just Work.

You would probably have to use a different location in CMOS to store the 
offset than what the guest relies on to read the current time.

Regards,

Anthony Liguori

> Do you suggest to set up a mechanism (in parallel to savevm/loadvm)
> where each device with non-volatile memory could register to? Probably,
> in most devices the SaveStateHandler could play the role of
> SaveNVStateHandler, but some would have to do something else. This would
> make the file.ram different than a memory dump.
>
> Regards,
>
>     Dan
>
>   

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Avi Kivity]

Anthony Liguori wrote:
>>
>> I'm not sure I understood what you suggest here.
>>
>> Plainly storing the rtc state on file is not enough, as unlike with real
>> hardware, nothing will advance it when the power is off.
>>   
>
> If you made the CMOS non-volatile, what you would store in the CMOS is 
> the clock-offset, not the actual clock time.  Then when the VM started 
> up again, it would Just Work.
>
> You would probably have to use a different location in CMOS to store 
> the offset than what the guest relies on to read the current time.

Under this, the CMOS would not be read by the guest at any time.  So why 
store the CMOS at all?  Store the offset somewhere and avoid the CMOS 
(gaining the ability to work on targets without nonvolatile memory).

It's config file territory, not CMOS.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> I'm not sure I understood what you suggest here.
>>>
>>> Plainly storing the rtc state on file is not enough, as unlike with 
>>> real
>>> hardware, nothing will advance it when the power is off.
>>>   
>>
>> If you made the CMOS non-volatile, what you would store in the CMOS 
>> is the clock-offset, not the actual clock time.  Then when the VM 
>> started up again, it would Just Work.
>>
>> You would probably have to use a different location in CMOS to store 
>> the offset than what the guest relies on to read the current time.
>
> Under this, the CMOS would not be read by the guest at any time.  So 
> why store the CMOS at all?  Store the offset somewhere and avoid the 
> CMOS (gaining the ability to work on targets without nonvolatile memory).
>
> It's config file territory, not CMOS.

It's a bios parameter (just like default boot device).  It makes sense 
to allow the bios to let the user customize bios parameters and have 
that be saved.

CMOS is non-volatile in real life so making it non-volatile in QEMU 
seems like the obvious thing to do.

Regards,

Anthony Liguori

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Tristan Gingold]

> It's a bios parameter (just like default boot device).  It makes  
> sense to allow the bios to let the user customize bios parameters  
> and have that be saved.
>
> CMOS is non-volatile in real life so making it non-volatile in QEMU  
> seems like the obvious thing to do.

I fully agree.  Platforms have many non-volatile storage (CMOS,  
ethernet eeproms, flashes...).  It would
be nice if qemu were able to making them non-volatile.

I'd plan to work on this, although not soon.

Tristan.

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Laurent Vivier]

Le mardi 06 mai 2008 à 10:26 +0200, Tristan Gingold a écrit :
> > It's a bios parameter (just like default boot device).  It makes  
> > sense to allow the bios to let the user customize bios parameters  
> > and have that be saved.
> >
> > CMOS is non-volatile in real life so making it non-volatile in QEMU  
> > seems like the obvious thing to do.
> 
> I fully agree.  Platforms have many non-volatile storage (CMOS,  
> ethernet eeproms, flashes...).  It would
> be nice if qemu were able to making them non-volatile.
> 
> I'd plan to work on this, although not soon.

Hervé Poussineau had already done this kind of work for DS1225Y chip.

The content of the NVRAM is saved into the file "nvram".

I think we should have a more generic way to manage this.
I mean:
- a parameter to specify the file
- a default filename per machine (something like "~/.qemu/pc.cmos",
"~/.qemu/sun4m.nvram" or "~/.qemu/ppc_oldworld.nvram")

(and if we create a "~/.qemu" directory, perhaps we could store some
default configurations ... :-P )

There is also the -prom-env parameter to specify a value of the nvram
(for sparc only, but could be generic).

Laurent
-- 
------------- Laurent.Vivier@bull.net ---------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Jamie Lokier]

Dan Kenigsberg wrote:
> These patches will allow doing the same with VM:
> - Before shutting a VM down, use the monitor's info timeoffset to see
>   how much (in seconds) does the rtc differ from the host clock.
> - Store this offset somewhere.
> - Use it next time with -startdate now+offset.

Another useful one would be store the actual time, and use the same
time when starting next time - without including any advance in host's
clock in the interval.

That's useful when running some time-limited software in a VM.  Then
you can only run the VM when you're using the software, and get more
use out of it before the time runs out.

-- Jamie

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Dan Kenigsberg]

On Sun, Apr 27, 2008 at 10:28:03PM +0100, Jamie Lokier wrote:
> Dan Kenigsberg wrote:
> > These patches will allow doing the same with VM:
> > - Before shutting a VM down, use the monitor's info timeoffset to see
> >   how much (in seconds) does the rtc differ from the host clock.
> > - Store this offset somewhere.
> > - Use it next time with -startdate now+offset.
> 
> Another useful one would be store the actual time, and use the same
> time when starting next time - without including any advance in host's
> clock in the interval.
> 
> That's useful when running some time-limited software in a VM.  Then
> you can only run the VM when you're using the software, and get more
> use out of it before the time runs out.
> 

It does not seem hard to add something like that (though it seems quite
orthogonal to my original perpose). Did you mean something like the
following?


diff --git a/monitor.c b/monitor.c
index 76817e1..45396aa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -264,6 +264,14 @@ static void do_info_blockstats(void)
     bdrv_info_stats();
 }
 
+void do_info_timedate(void)
+{
+    struct tm tm;
+    qemu_get_timedate(&tm, 0);
+    term_printf("%d-%02d-%02dT%02d:%02d:%02d\n", tm.tm_year + 1900, tm.tm_mon,
+            tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
+}
+
 /* get the current CPU defined by the user */
 static int mon_set_cpu(int cpu_index)
 {
@@ -1410,6 +1418,8 @@ static term_cmd_t info_cmds[] = {
     { "timeoffset", "", do_info_timeoffset,
       "", "show how much the VM real time clock differ from host time" },
 #endif
+    { "timedate", "", do_info_timedate,
+      "", "show the current VM time and date" },
     { "name", "", do_info_name,
       "", "show the current VM name" },
 #if defined(TARGET_PPC)

Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock

[Sergey Bychkov]

> Another useful one would be store the actual time, and use the same
> time when starting next time - without including any advance in host's
> clock in the interval.
> 
> That's useful when running some time-limited software in a VM.  Then
> you can only run the VM when you're using the software, and get more
> use out of it before the time runs out.

Run it with fixed -startdate and/or in snapshot mode