[Qemu-devel] [PATCH 0/5] Refactor and enhance RTC configuration

[Qemu-devel] [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

The aim of this series is to allow using the emulated PC RTC (MC146818)
as a reliable time source for guests. This is particularly useful if the
host runs NTP or has otherwise access to an accurate clock while the
guest has not (no network, impossible to add an NTP implementation
etc.).

To achieve this, the command line switch -rtc is introduced. It takes
the option 'clock' to switch between the currently used base ('vm') and
the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
deprecate all the other RTC-related stand-alone switches.

First tests indicate that this approach works as expected and could
increase the usefulness of the virtual RTC enormously. However, there
might be pitfalls I've missed so far. Feedback would be welcome!

Find this series also at git://git.kiszka.org/qemu.git queues/clock

Jan Kiszka (5):
      Rename QEMU_TIMER_* to QEMU_CLOCK_*
      win32: Drop dead dyntick timer code
      Introduce QEMU_CLOCK_HOST
      Refactor RTC command line switches
      Enable host-clock-based RTC

 hw/mc146818rtc.c |   35 ++++-----
 qemu-options.hx  |   52 +++++++-----
 sysemu.h         |    2 +
 vl.c             |  234 ++++++++++++++++++++++++++++++++++++------------------
 4 files changed, 205 insertions(+), 118 deletions(-)

[Qemu-devel] [PATCH 1/5] Rename QEMU_TIMER_* to QEMU_CLOCK_*

[Jan Kiszka]

These constants select clocks, not timers. And init_timers initializes
clocks.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 vl.c |   54 +++++++++++++++++++++++++++---------------------------
 1 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/vl.c b/vl.c
index 098daaa..872083d 100644
--- a/vl.c
+++ b/vl.c
@@ -529,7 +529,7 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c)
 /***********************************************************/
 /* real time host monotonic timer */
 
-#define QEMU_TIMER_BASE 1000000000LL
+#define QEMU_CLOCK_BASE 1000000000LL
 
 #ifdef WIN32
 
@@ -551,7 +551,7 @@ static int64_t get_clock(void)
 {
     LARGE_INTEGER ti;
     QueryPerformanceCounter(&ti);
-    return muldiv64(ti.QuadPart, QEMU_TIMER_BASE, clock_freq);
+    return muldiv64(ti.QuadPart, QEMU_CLOCK_BASE, clock_freq);
 }
 
 #else
@@ -671,8 +671,8 @@ void cpu_disable_ticks(void)
 /***********************************************************/
 /* timers */
 
-#define QEMU_TIMER_REALTIME 0
-#define QEMU_TIMER_VIRTUAL  1
+#define QEMU_CLOCK_REALTIME 0
+#define QEMU_CLOCK_VIRTUAL  1
 
 struct QEMUClock {
     int type;
@@ -754,7 +754,7 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t);
    fairly approximate, so ignore small variation.
    When the guest is idle real and virtual time will be aligned in
    the IO wait loop.  */
-#define ICOUNT_WOBBLE (QEMU_TIMER_BASE / 10)
+#define ICOUNT_WOBBLE (QEMU_CLOCK_BASE / 10)
 
 static void icount_adjust(void)
 {
@@ -796,7 +796,7 @@ static void icount_adjust_rt(void * opaque)
 static void icount_adjust_vm(void * opaque)
 {
     qemu_mod_timer(icount_vm_timer,
-                   qemu_get_clock(vm_clock) + QEMU_TIMER_BASE / 10);
+                   qemu_get_clock(vm_clock) + QEMU_CLOCK_BASE / 10);
     icount_adjust();
 }
 
@@ -812,7 +812,7 @@ static void init_icount_adjust(void)
                    qemu_get_clock(rt_clock) + 1000);
     icount_vm_timer = qemu_new_timer(vm_clock, icount_adjust_vm, NULL);
     qemu_mod_timer(icount_vm_timer,
-                   qemu_get_clock(vm_clock) + QEMU_TIMER_BASE / 10);
+                   qemu_get_clock(vm_clock) + QEMU_CLOCK_BASE / 10);
 }
 
 static struct qemu_alarm_timer alarm_timers[] = {
@@ -1020,10 +1020,10 @@ static void qemu_run_timers(QEMUTimer **ptimer_head, int64_t current_time)
 int64_t qemu_get_clock(QEMUClock *clock)
 {
     switch(clock->type) {
-    case QEMU_TIMER_REALTIME:
+    case QEMU_CLOCK_REALTIME:
         return get_clock() / 1000000;
     default:
-    case QEMU_TIMER_VIRTUAL:
+    case QEMU_CLOCK_VIRTUAL:
         if (use_icount) {
             return cpu_get_icount();
         } else {
@@ -1032,12 +1032,12 @@ int64_t qemu_get_clock(QEMUClock *clock)
     }
 }
 
-static void init_timers(void)
+static void init_clocks(void)
 {
     init_get_clock();
-    ticks_per_sec = QEMU_TIMER_BASE;
-    rt_clock = qemu_new_clock(QEMU_TIMER_REALTIME);
-    vm_clock = qemu_new_clock(QEMU_TIMER_VIRTUAL);
+    ticks_per_sec = QEMU_CLOCK_BASE;
+    rt_clock = qemu_new_clock(QEMU_CLOCK_REALTIME);
+    vm_clock = qemu_new_clock(QEMU_CLOCK_VIRTUAL);
 }
 
 /* save a timer */
@@ -1131,9 +1131,9 @@ static void host_alarm_handler(int host_signum)
 #endif
     if (alarm_has_dynticks(alarm_timer) ||
         (!use_icount &&
-            qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
+            qemu_timer_expired(active_timers[QEMU_CLOCK_VIRTUAL],
                                qemu_get_clock(vm_clock))) ||
-        qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
+        qemu_timer_expired(active_timers[QEMU_CLOCK_REALTIME],
                            qemu_get_clock(rt_clock))) {
         qemu_event_increment();
         if (alarm_timer) alarm_timer->flags |= ALARM_FLAG_EXPIRED;
@@ -1153,8 +1153,8 @@ static int64_t qemu_next_deadline(void)
 {
     int64_t delta;
 
-    if (active_timers[QEMU_TIMER_VIRTUAL]) {
-        delta = active_timers[QEMU_TIMER_VIRTUAL]->expire_time -
+    if (active_timers[QEMU_CLOCK_VIRTUAL]) {
+        delta = active_timers[QEMU_CLOCK_VIRTUAL]->expire_time -
                      qemu_get_clock(vm_clock);
     } else {
         /* To avoid problems with overflow limit this to 2^32.  */
@@ -1178,8 +1178,8 @@ static uint64_t qemu_next_deadline_dyntick(void)
     else
         delta = (qemu_next_deadline() + 999) / 1000;
 
-    if (active_timers[QEMU_TIMER_REALTIME]) {
-        rtdelta = (active_timers[QEMU_TIMER_REALTIME]->expire_time -
+    if (active_timers[QEMU_CLOCK_REALTIME]) {
+        rtdelta = (active_timers[QEMU_CLOCK_REALTIME]->expire_time -
                  qemu_get_clock(rt_clock))*1000;
         if (rtdelta < delta)
             delta = rtdelta;
@@ -1361,8 +1361,8 @@ static void dynticks_rearm_timer(struct qemu_alarm_timer *t)
     int64_t nearest_delta_us = INT64_MAX;
     int64_t current_us;
 
-    if (!active_timers[QEMU_TIMER_REALTIME] &&
-                !active_timers[QEMU_TIMER_VIRTUAL])
+    if (!active_timers[QEMU_CLOCK_REALTIME] &&
+        !active_timers[QEMU_CLOCK_VIRTUAL])
         return;
 
     nearest_delta_us = qemu_next_deadline_dyntick();
@@ -1477,8 +1477,8 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t)
     struct qemu_alarm_win32 *data = t->priv;
     uint64_t nearest_delta_us;
 
-    if (!active_timers[QEMU_TIMER_REALTIME] &&
-                !active_timers[QEMU_TIMER_VIRTUAL])
+    if (!active_timers[QEMU_CLOCK_REALTIME] &&
+        !active_timers[QEMU_CLOCK_VIRTUAL])
         return;
 
     nearest_delta_us = qemu_next_deadline_dyntick();
@@ -4124,12 +4124,12 @@ void main_loop_wait(int timeout)
     /* vm time timers */
     if (vm_running) {
         if (!cur_cpu || likely(!(cur_cpu->singlestep_enabled & SSTEP_NOTIMER)))
-            qemu_run_timers(&active_timers[QEMU_TIMER_VIRTUAL],
-                qemu_get_clock(vm_clock));
+            qemu_run_timers(&active_timers[QEMU_CLOCK_VIRTUAL],
+                            qemu_get_clock(vm_clock));
     }
 
     /* real time timers */
-    qemu_run_timers(&active_timers[QEMU_TIMER_REALTIME],
+    qemu_run_timers(&active_timers[QEMU_CLOCK_REALTIME],
                     qemu_get_clock(rt_clock));
 
     /* Check bottom-halves last in case any of the earlier events triggered
@@ -5757,7 +5757,7 @@ int main(int argc, char **argv, char **envp)
     setvbuf(stdout, NULL, _IOLBF, 0);
 #endif
 
-    init_timers();
+    init_clocks();
     if (init_timer_alarm() < 0) {
         fprintf(stderr, "could not initialize alarm timer\n");
         exit(1);

[Qemu-devel] [PATCH 3/5] Introduce QEMU_CLOCK_HOST

[Jan Kiszka]

Despite its name QEMU_CLOCK_REALTIME is (normally) not using
CLOCK_REALTIME / the host system time as base. In order to allow also
non-trivial RTC emulations (MC146818) to follow the host time instead of
the virtual guest time, introduce the new clock type QEMU_CLOCK_HOST. It
is unconditionally based on CLOCK_REALTIME, thus will follow system time
changes of the host.

The only limitation of its current implementation is that pending
host_clock timers may not fire early if the host time is pushed forward
beyond their expiry. So far no urgent need to overcome this limitation
was identified, so it's left as simple as it is (expiry on next alarm
timer tick).

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 vl.c |   46 +++++++++++++++++++++++++++++++++++-----------
 1 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/vl.c b/vl.c
index e56207c..2e36c6a 100644
--- a/vl.c
+++ b/vl.c
@@ -531,6 +531,14 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c)
 
 #define QEMU_CLOCK_BASE 1000000000LL
 
+static int64_t get_clock_realtime(void)
+{
+    struct timeval tv;
+
+    gettimeofday(&tv, NULL);
+    return tv.tv_sec * 1000000000LL + (tv.tv_usec * 1000);
+}
+
 #ifdef WIN32
 
 static int64_t clock_freq;
@@ -585,9 +593,7 @@ static int64_t get_clock(void)
     {
         /* XXX: using gettimeofday leads to problems if the date
            changes, so it should be avoided. */
-        struct timeval tv;
-        gettimeofday(&tv, NULL);
-        return tv.tv_sec * 1000000000LL + (tv.tv_usec * 1000);
+        return get_clock_realtime();
     }
 }
 #endif
@@ -673,6 +679,7 @@ void cpu_disable_ticks(void)
 
 #define QEMU_CLOCK_REALTIME 0
 #define QEMU_CLOCK_VIRTUAL  1
+#define QEMU_CLOCK_HOST     2
 
 struct QEMUClock {
     int type;
@@ -899,10 +906,13 @@ next:
     }
 }
 
+#define QEMU_NUM_CLOCKS 3
+
 QEMUClock *rt_clock;
 QEMUClock *vm_clock;
+QEMUClock *host_clock;
 
-static QEMUTimer *active_timers[2];
+static QEMUTimer *active_timers[QEMU_NUM_CLOCKS];
 
 static QEMUClock *qemu_new_clock(int type)
 {
@@ -1029,6 +1039,8 @@ int64_t qemu_get_clock(QEMUClock *clock)
         } else {
             return cpu_get_clock();
         }
+    case QEMU_CLOCK_HOST:
+        return get_clock_realtime();
     }
 }
 
@@ -1038,6 +1050,7 @@ static void init_clocks(void)
     ticks_per_sec = QEMU_CLOCK_BASE;
     rt_clock = qemu_new_clock(QEMU_CLOCK_REALTIME);
     vm_clock = qemu_new_clock(QEMU_CLOCK_VIRTUAL);
+    host_clock = qemu_new_clock(QEMU_CLOCK_HOST);
 }
 
 /* save a timer */
@@ -1134,7 +1147,9 @@ static void host_alarm_handler(int host_signum)
             qemu_timer_expired(active_timers[QEMU_CLOCK_VIRTUAL],
                                qemu_get_clock(vm_clock))) ||
         qemu_timer_expired(active_timers[QEMU_CLOCK_REALTIME],
-                           qemu_get_clock(rt_clock))) {
+                           qemu_get_clock(rt_clock)) ||
+        qemu_timer_expired(active_timers[QEMU_CLOCK_HOST],
+                           qemu_get_clock(host_clock))) {
         qemu_event_increment();
         if (alarm_timer) alarm_timer->flags |= ALARM_FLAG_EXPIRED;
 
@@ -1151,14 +1166,18 @@ static void host_alarm_handler(int host_signum)
 
 static int64_t qemu_next_deadline(void)
 {
-    int64_t delta;
+    /* To avoid problems with overflow limit this to 2^32.  */
+    int64_t delta = INT32_MAX;
 
     if (active_timers[QEMU_CLOCK_VIRTUAL]) {
         delta = active_timers[QEMU_CLOCK_VIRTUAL]->expire_time -
                      qemu_get_clock(vm_clock);
-    } else {
-        /* To avoid problems with overflow limit this to 2^32.  */
-        delta = INT32_MAX;
+    }
+    if (active_timers[QEMU_CLOCK_HOST]) {
+        int64_t hdelta = active_timers[QEMU_CLOCK_HOST]->expire_time -
+                 qemu_get_clock(host_clock);
+        if (hdelta < delta)
+            delta = hdelta;
     }
 
     if (delta < 0)
@@ -1362,7 +1381,8 @@ static void dynticks_rearm_timer(struct qemu_alarm_timer *t)
     int64_t current_us;
 
     if (!active_timers[QEMU_CLOCK_REALTIME] &&
-        !active_timers[QEMU_CLOCK_VIRTUAL])
+        !active_timers[QEMU_CLOCK_VIRTUAL] &&
+        !active_timers[QEMU_CLOCK_HOST])
         return;
 
     nearest_delta_us = qemu_next_deadline_dyntick();
@@ -1477,7 +1497,8 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t)
     struct qemu_alarm_win32 *data = t->priv;
 
     if (!active_timers[QEMU_CLOCK_REALTIME] &&
-        !active_timers[QEMU_CLOCK_VIRTUAL])
+        !active_timers[QEMU_CLOCK_VIRTUAL] &&
+        !active_timers[QEMU_CLOCK_HOST])
         return;
 
     timeKillEvent(data->timerId);
@@ -4128,6 +4149,9 @@ void main_loop_wait(int timeout)
     qemu_run_timers(&active_timers[QEMU_CLOCK_REALTIME],
                     qemu_get_clock(rt_clock));
 
+    qemu_run_timers(&active_timers[QEMU_CLOCK_HOST],
+                    qemu_get_clock(host_clock));
+
     /* Check bottom-halves last in case any of the earlier events triggered
        them.  */
     qemu_bh_poll();

[Qemu-devel] [PATCH 5/5] Enable host-clock-based RTC

[Jan Kiszka]

Allow RTC emulations to use the new host_clock instead of vm_clock. This
has the advantage that the emulated RTC will follow automatically the
host time while it might be tuned via NTP.

Note that some RTC emulations (at least M48T59) already use the host
time unconditionally while others (namely MC146818) do not. This patch
introduces the required infrastructure for selecting the base clock and
only converts MC146818 for now.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 hw/mc146818rtc.c |   35 ++++++++++++++++-------------------
 qemu-options.hx  |   14 ++++++++++----
 sysemu.h         |    1 +
 vl.c             |   15 ++++++++++++++-
 4 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 5c8676e..d339b7a 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -107,8 +107,8 @@ static void rtc_coalesced_timer_update(RTCState *s)
     } else {
         /* divide each RTC interval to 2 - 8 smaller intervals */
         int c = MIN(s->irq_coalesced, 7) + 1; 
-        int64_t next_clock = qemu_get_clock(vm_clock) +
-		muldiv64(s->period / c, ticks_per_sec, 32768);
+        int64_t next_clock = qemu_get_clock(rtc_clock) +
+            muldiv64(s->period / c, ticks_per_sec, 32768);
         qemu_mod_timer(s->coalesced_timer, next_clock);
     }
 }
@@ -231,7 +231,7 @@ static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
             /* UIP bit is read only */
             s->cmos_data[RTC_REG_A] = (data & ~REG_A_UIP) |
                 (s->cmos_data[RTC_REG_A] & REG_A_UIP);
-            rtc_timer_update(s, qemu_get_clock(vm_clock));
+            rtc_timer_update(s, qemu_get_clock(rtc_clock));
             break;
         case RTC_REG_B:
             if (data & REG_B_SET) {
@@ -245,7 +245,7 @@ static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
                 }
             }
             s->cmos_data[RTC_REG_B] = data;
-            rtc_timer_update(s, qemu_get_clock(vm_clock));
+            rtc_timer_update(s, qemu_get_clock(rtc_clock));
             break;
         case RTC_REG_C:
         case RTC_REG_D:
@@ -604,18 +604,17 @@ RTCState *rtc_init_sqw(int base, qemu_irq irq, qemu_irq sqw_irq, int base_year)
     s->base_year = base_year;
     rtc_set_date_from_host(s);
 
-    s->periodic_timer = qemu_new_timer(vm_clock,
-                                       rtc_periodic_timer, s);
+    s->periodic_timer = qemu_new_timer(rtc_clock, rtc_periodic_timer, s);
 #ifdef TARGET_I386
     if (rtc_td_hack)
-        s->coalesced_timer = qemu_new_timer(vm_clock, rtc_coalesced_timer, s);
+        s->coalesced_timer =
+            qemu_new_timer(rtc_clock, rtc_coalesced_timer, s);
 #endif
-    s->second_timer = qemu_new_timer(vm_clock,
-                                     rtc_update_second, s);
-    s->second_timer2 = qemu_new_timer(vm_clock,
-                                      rtc_update_second2, s);
+    s->second_timer = qemu_new_timer(rtc_clock, rtc_update_second, s);
+    s->second_timer2 = qemu_new_timer(rtc_clock, rtc_update_second2, s);
 
-    s->next_second_time = qemu_get_clock(vm_clock) + (ticks_per_sec * 99) / 100;
+    s->next_second_time =
+        qemu_get_clock(rtc_clock) + (ticks_per_sec * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
 
     register_ioport_write(base, 2, 1, cmos_ioport_write, s);
@@ -725,14 +724,12 @@ RTCState *rtc_mm_init(target_phys_addr_t base, int it_shift, qemu_irq irq,
     s->base_year = base_year;
     rtc_set_date_from_host(s);
 
-    s->periodic_timer = qemu_new_timer(vm_clock,
-                                       rtc_periodic_timer, s);
-    s->second_timer = qemu_new_timer(vm_clock,
-                                     rtc_update_second, s);
-    s->second_timer2 = qemu_new_timer(vm_clock,
-                                      rtc_update_second2, s);
+    s->periodic_timer = qemu_new_timer(rtc_clock, rtc_periodic_timer, s);
+    s->second_timer = qemu_new_timer(rtc_clock, rtc_update_second, s);
+    s->second_timer2 = qemu_new_timer(rtc_clock, rtc_update_second2, s);
 
-    s->next_second_time = qemu_get_clock(vm_clock) + (ticks_per_sec * 99) / 100;
+    s->next_second_time =
+        qemu_get_clock(rtc_clock) + (ticks_per_sec * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
 
     io_memory = cpu_register_io_memory(rtc_mm_read, rtc_mm_write, s);
diff --git a/qemu-options.hx b/qemu-options.hx
index ea672ee..253180b 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1498,22 +1498,28 @@ DEF("startdate", HAS_ARG, QEMU_OPTION_startdate, "")
 
 #ifdef TARGET_I386
 DEF("rtc", HAS_ARG, QEMU_OPTION_rtc, \
-    "-rtc [base=utc|localtime|date][,drift-fix=on|off]\n" \
-    "                Set the RTC base, enable Windows time drift fix\n")
+    "-rtc [base=utc|localtime|date][,clock=vm|host][,drift-fix=on|off]\n" \
+    "                Set the RTC base and clock, enable Windows time drift fix\n")
 #else
 DEF("rtc", HAS_ARG, QEMU_OPTION_rtc, \
-    "-rtc [base=utc|localtime|date]\n" \
+    "-rtc [base=utc|localtime|date][,clock=vm|host]\n" \
     "                Set the RTC base and clock\n")
 #endif
 
 STEXI
 
-@item -rtc [base=utc|localtime|@var{date}][,drift-fix=on|off]
+@item -rtc [base=utc|localtime|@var{date}][,clock=vm|rt][,drift-fix=on|off]
 Specify @option{base} as @code{utc} or @code{localtime} to let the RTC start at the current
 UTC or local time, respectively. @code{localtime} is required for correct date in
 MS-DOS or Windows. To start at a specific point in time, provide @var{date} in the
 format @code{2006-06-17T16:01:21} or @code{2006-06-17}. The default base is UTC.
 
+By default the RTC is driven by a virtual clock (@code{vm}) which is not subject
+to host time adjustments and does not jump when the guest is supended and
+resumed or migrated. To use the host's system time instead, set @option{clock} to
+@code{host}. This is useful if the host time is smoothly following an accurate
+reference clock, e.g. via NTP, and wants to propagate this into the guest.
+
 Enable @option{drift-fix} (i386 targets only) if you experience time drift problems
 in Windows with ACPI HAL. This option will try to figure out how many timer
 interrupts were not processed by the Windows guest and will re-inject them.
diff --git a/sysemu.h b/sysemu.h
index a018b47..fe4eb53 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -135,6 +135,7 @@ extern int no_quit;
 extern int semihosting_enabled;
 extern int old_param;
 extern int boot_menu;
+extern QEMUClock *rtc_clock;
 
 #define MAX_NODES 64
 extern int nb_numa_nodes;
diff --git a/vl.c b/vl.c
index 8437d2c..52bfefe 100644
--- a/vl.c
+++ b/vl.c
@@ -194,6 +194,7 @@ int vm_running;
 int autostart;
 static int rtc_utc = 1;
 static int rtc_date_offset = -1; /* -1 means no change */
+QEMUClock *rtc_clock;
 int vga_interface_type = VGA_CIRRUS;
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
@@ -1051,6 +1052,8 @@ static void init_clocks(void)
     rt_clock = qemu_new_clock(QEMU_CLOCK_REALTIME);
     vm_clock = qemu_new_clock(QEMU_CLOCK_VIRTUAL);
     host_clock = qemu_new_clock(QEMU_CLOCK_HOST);
+
+    rtc_clock = vm_clock;
 }
 
 /* save a timer */
@@ -1630,7 +1633,7 @@ static void configure_rtc_date_offset(const char *startdate, int legacy)
 static void configure_rtc(const char *options)
 {
     static const char * const params[] = {
-        "base",
+        "base", "clock",
 #ifdef CONFIG_TARGET_I386
         "td-hack",
 #endif
@@ -1652,6 +1655,16 @@ static void configure_rtc(const char *options)
             configure_rtc_date_offset(buf, 0);
         }
     }
+    if (get_param_value(buf, sizeof(buf), "clock", options)) {
+        if (!strcmp(buf, "vm")) {
+            rtc_clock = vm_clock;
+        } else if (!strcmp(buf, "host")) {
+            rtc_clock = host_clock;
+        } else {
+            fprintf(stderr, "qemu: invalid option value '%s'\n", buf);
+            exit(1);
+        }
+    }
 #ifdef CONFIG_TARGET_I386
     if (get_param_value(buf, sizeof(buf), "drift-hack", options)) {
         if (!strcmp(buf, "on")) {

[Qemu-devel] [PATCH 2/5] win32: Drop dead dyntick timer code

[Jan Kiszka]

nearest_delta_us is calculated but not used. Drop it.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 vl.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/vl.c b/vl.c
index 872083d..e56207c 100644
--- a/vl.c
+++ b/vl.c
@@ -1167,7 +1167,7 @@ static int64_t qemu_next_deadline(void)
     return delta;
 }
 
-#if defined(__linux__) || defined(_WIN32)
+#if defined(__linux__)
 static uint64_t qemu_next_deadline_dyntick(void)
 {
     int64_t delta;
@@ -1475,15 +1475,11 @@ static void win32_stop_timer(struct qemu_alarm_timer *t)
 static void win32_rearm_timer(struct qemu_alarm_timer *t)
 {
     struct qemu_alarm_win32 *data = t->priv;
-    uint64_t nearest_delta_us;
 
     if (!active_timers[QEMU_CLOCK_REALTIME] &&
         !active_timers[QEMU_CLOCK_VIRTUAL])
         return;
 
-    nearest_delta_us = qemu_next_deadline_dyntick();
-    nearest_delta_us /= 1000;
-
     timeKillEvent(data->timerId);
 
     data->timerId = timeSetEvent(1,

[Qemu-devel] [PATCH 4/5] Refactor RTC command line switches

[Jan Kiszka]

Deprecate -localtime, -setdate and -rtc-td-hack in favor of a new
unified command line switch:

    -rtc [base=utc|localtime|@var{date}][,drift-fix=on|off]

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 qemu-options.hx |   46 +++++++++++----------
 sysemu.h        |    1 
 vl.c            |  121 ++++++++++++++++++++++++++++++++++++++-----------------
 3 files changed, 109 insertions(+), 59 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index ce38a3b..ea672ee 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -681,15 +681,9 @@ slows down the IDE transfers).
 ETEXI
 
 #ifdef TARGET_I386
-DEF("rtc-td-hack", 0, QEMU_OPTION_rtc_td_hack,
-    "-rtc-td-hack    use it to fix time drift in Windows ACPI HAL\n")
+HXCOMM Deprecated by -rtc
+DEF("rtc-td-hack", 0, QEMU_OPTION_rtc_td_hack, "")
 #endif
-STEXI
-@item -rtc-td-hack
-Use it if you experience time drift problem in Windows with ACPI HAL.
-This option will try to figure out how many timer interrupts were not
-processed by the Windows guest and will re-inject them.
-ETEXI
 
 #ifdef TARGET_I386
 DEF("no-fd-bootchk", 0, QEMU_OPTION_no_fd_bootchk,
@@ -1498,23 +1492,31 @@ Force the use of the given methods for timer alarm. To see what timers
 are available use -clock ?.
 ETEXI
 
-DEF("localtime", 0, QEMU_OPTION_localtime, \
-    "-localtime      set the real time clock to local time [default=utc]\n")
-STEXI
-@item -localtime
-Set the real time clock to local time (the default is to UTC
-time). This option is needed to have correct date in MS-DOS or
-Windows.
-ETEXI
+HXCOMM Options deprecated by -rtc
+DEF("localtime", 0, QEMU_OPTION_localtime, "")
+DEF("startdate", HAS_ARG, QEMU_OPTION_startdate, "")
+
+#ifdef TARGET_I386
+DEF("rtc", HAS_ARG, QEMU_OPTION_rtc, \
+    "-rtc [base=utc|localtime|date][,drift-fix=on|off]\n" \
+    "                Set the RTC base, enable Windows time drift fix\n")
+#else
+DEF("rtc", HAS_ARG, QEMU_OPTION_rtc, \
+    "-rtc [base=utc|localtime|date]\n" \
+    "                Set the RTC base and clock\n")
+#endif
 
-DEF("startdate", HAS_ARG, QEMU_OPTION_startdate, \
-    "-startdate      select initial date of the clock\n")
 STEXI
 
-@item -startdate @var{date}
-Set the initial date of the real time clock. Valid formats for
-@var{date} are: @code{now} or @code{2006-06-17T16:01:21} or
-@code{2006-06-17}. The default value is @code{now}.
+@item -rtc [base=utc|localtime|@var{date}][,drift-fix=on|off]
+Specify @option{base} as @code{utc} or @code{localtime} to let the RTC start at the current
+UTC or local time, respectively. @code{localtime} is required for correct date in
+MS-DOS or Windows. To start at a specific point in time, provide @var{date} in the
+format @code{2006-06-17T16:01:21} or @code{2006-06-17}. The default base is UTC.
+
+Enable @option{drift-fix} (i386 targets only) if you experience time drift problems
+in Windows with ACPI HAL. This option will try to figure out how many timer
+interrupts were not processed by the Windows guest and will re-inject them.
 ETEXI
 
 DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
diff --git a/sysemu.h b/sysemu.h
index ac16c21..a018b47 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -4,6 +4,7 @@
 
 #include "qemu-common.h"
 #include "qemu-option.h"
+#include "qemu-timer.h"
 #include "sys-queue.h"
 #include "qdict.h"
 
diff --git a/vl.c b/vl.c
index 2e36c6a..8437d2c 100644
--- a/vl.c
+++ b/vl.c
@@ -1588,6 +1588,84 @@ int qemu_timedate_diff(struct tm *tm)
     return seconds - time(NULL);
 }
 
+static void configure_rtc_date_offset(const char *startdate, int legacy)
+{
+    time_t rtc_start_date;
+    struct tm tm;
+
+    if (!strcmp(startdate, "now") && legacy) {
+        rtc_date_offset = -1;
+    } else {
+        if (sscanf(startdate, "%d-%d-%dT%d:%d:%d",
+                   &tm.tm_year,
+                   &tm.tm_mon,
+                   &tm.tm_mday,
+                   &tm.tm_hour,
+                   &tm.tm_min,
+                   &tm.tm_sec) == 6) {
+            /* OK */
+        } else if (sscanf(startdate, "%d-%d-%d",
+                          &tm.tm_year,
+                          &tm.tm_mon,
+                          &tm.tm_mday) == 3) {
+            tm.tm_hour = 0;
+            tm.tm_min = 0;
+            tm.tm_sec = 0;
+        } else {
+            goto date_fail;
+        }
+        tm.tm_year -= 1900;
+        tm.tm_mon--;
+        rtc_start_date = mktimegm(&tm);
+        if (rtc_start_date == -1) {
+        date_fail:
+            fprintf(stderr, "Invalid date format. Valid format are:\n"
+                            "'2006-06-17T16:01:21' or '2006-06-17'\n");
+            exit(1);
+        }
+        rtc_date_offset = time(NULL) - rtc_start_date;
+    }
+}
+
+static void configure_rtc(const char *options)
+{
+    static const char * const params[] = {
+        "base",
+#ifdef CONFIG_TARGET_I386
+        "td-hack",
+#endif
+        NULL
+    };
+    char buf[1024];
+
+    if (check_params(buf, sizeof(buf), params, options) < 0) {
+        fprintf(stderr, "qemu: unknown rtc parameter '%s' in '%s'\n",
+                buf, options);
+        exit(1);
+    }
+    if (get_param_value(buf, sizeof(buf), "base", options)) {
+        if (!strcmp(buf, "utc")) {
+            rtc_utc = 1;
+        } else if (!strcmp(buf, "localtime")) {
+            rtc_utc = 0;
+        } else {
+            configure_rtc_date_offset(buf, 0);
+        }
+    }
+#ifdef CONFIG_TARGET_I386
+    if (get_param_value(buf, sizeof(buf), "drift-hack", options)) {
+        if (!strcmp(buf, "on")) {
+            rtc_td_hack = 1;
+        } else if (!strcmp(buf, "off")) {
+            rtc_td_hack = 0;
+        } else {
+            fprintf(stderr, "qemu: invalid option value '%s'\n", buf);
+            exit(1);
+        }
+    }
+#endif
+}
+
 #ifdef _WIN32
 static void socket_cleanup(void)
 {
@@ -4905,6 +4983,8 @@ int main(int argc, char **argv, char **envp)
     CPUState *env;
     int show_vnc_port = 0;
 
+    init_clocks();
+
     qemu_errors_to_file(stderr);
     qemu_cache_utils_init(envp);
 
@@ -5591,42 +5671,10 @@ int main(int argc, char **argv, char **envp)
                 configure_alarms(optarg);
                 break;
             case QEMU_OPTION_startdate:
-                {
-                    struct tm tm;
-                    time_t rtc_start_date;
-                    if (!strcmp(optarg, "now")) {
-                        rtc_date_offset = -1;
-                    } else {
-                        if (sscanf(optarg, "%d-%d-%dT%d:%d:%d",
-                               &tm.tm_year,
-                               &tm.tm_mon,
-                               &tm.tm_mday,
-                               &tm.tm_hour,
-                               &tm.tm_min,
-                               &tm.tm_sec) == 6) {
-                            /* OK */
-                        } else if (sscanf(optarg, "%d-%d-%d",
-                                          &tm.tm_year,
-                                          &tm.tm_mon,
-                                          &tm.tm_mday) == 3) {
-                            tm.tm_hour = 0;
-                            tm.tm_min = 0;
-                            tm.tm_sec = 0;
-                        } else {
-                            goto date_fail;
-                        }
-                        tm.tm_year -= 1900;
-                        tm.tm_mon--;
-                        rtc_start_date = mktimegm(&tm);
-                        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");
-                            exit(1);
-                        }
-                        rtc_date_offset = time(NULL) - rtc_start_date;
-                    }
-                }
+                configure_rtc_date_offset(optarg, 1);
+                break;
+            case QEMU_OPTION_rtc:
+                configure_rtc(optarg);
                 break;
             case QEMU_OPTION_tb_size:
                 tb_size = strtol(optarg, NULL, 0);
@@ -5777,7 +5825,6 @@ int main(int argc, char **argv, char **envp)
     setvbuf(stdout, NULL, _IOLBF, 0);
 #endif
 
-    init_clocks();
     if (init_timer_alarm() < 0) {
         fprintf(stderr, "could not initialize alarm timer\n");
         exit(1);

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Anthony Liguori]

Jan Kiszka wrote:
> The aim of this series is to allow using the emulated PC RTC (MC146818)
> as a reliable time source for guests. This is particularly useful if the
> host runs NTP or has otherwise access to an accurate clock while the
> guest has not (no network, impossible to add an NTP implementation
> etc.).
>
> To achieve this, the command line switch -rtc is introduced. It takes
> the option 'clock' to switch between the currently used base ('vm') and
> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
> deprecate all the other RTC-related stand-alone switches.
>
> First tests indicate that this approach works as expected and could
> increase the usefulness of the virtual RTC enormously. However, there
> might be pitfalls I've missed so far. Feedback would be welcome!
>   

You get most of this pretty cheaply with qdev conversion.  If you give 
the rtc a default id, you can tweak all of the properties with the -set 
command line option.  It also provides a mechanism to change the default 
properties between machine types/versions which is ideal as we can 
introduce a kvm-specific machine type where we enable some of these 
things by default.

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>> as a reliable time source for guests. This is particularly useful if the
>> host runs NTP or has otherwise access to an accurate clock while the
>> guest has not (no network, impossible to add an NTP implementation
>> etc.).
>>
>> To achieve this, the command line switch -rtc is introduced. It takes
>> the option 'clock' to switch between the currently used base ('vm') and
>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
>> deprecate all the other RTC-related stand-alone switches.
>>
>> First tests indicate that this approach works as expected and could
>> increase the usefulness of the virtual RTC enormously. However, there
>> might be pitfalls I've missed so far. Feedback would be welcome!
>>   
> 
> You get most of this pretty cheaply with qdev conversion.  If you give
> the rtc a default id, you can tweak all of the properties with the -set
> command line option.  It also provides a mechanism to change the default
> properties between machine types/versions which is ideal as we can
> introduce a kvm-specific machine type where we enable some of these
> things by default.
> 

Hmm, the refactoring of the old command line switches to -rtc is, if I
understand qdev and -set correctly, widely orthogonal. Or is the policy
now to freeze all command line switches in favor of the -device and
-set?. However, I will look into qdev conversion of the PC RTC.

Besides the interface thing, I'm also interesting in comments on the
other core idea, the selectable RTC base clock. Do we want this knob? Do
we want host_clock unconditionally? Or should the other RTC that
currently use the host time already also gain vm_clock support over the
time?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>> Jan Kiszka wrote:
>>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>>> as a reliable time source for guests. This is particularly useful if the
>>> host runs NTP or has otherwise access to an accurate clock while the
>>> guest has not (no network, impossible to add an NTP implementation
>>> etc.).
>>>
>>> To achieve this, the command line switch -rtc is introduced. It takes
>>> the option 'clock' to switch between the currently used base ('vm') and
>>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
>>> deprecate all the other RTC-related stand-alone switches.
>>>
>>> First tests indicate that this approach works as expected and could
>>> increase the usefulness of the virtual RTC enormously. However, there
>>> might be pitfalls I've missed so far. Feedback would be welcome!
>>>   
>> You get most of this pretty cheaply with qdev conversion.  If you give
>> the rtc a default id, you can tweak all of the properties with the -set
>> command line option.  It also provides a mechanism to change the default
>> properties between machine types/versions which is ideal as we can
>> introduce a kvm-specific machine type where we enable some of these
>> things by default.
>>
> 
> Hmm, the refactoring of the old command line switches to -rtc is, if I
> understand qdev and -set correctly, widely orthogonal. Or is the policy
> now to freeze all command line switches in favor of the -device and
> -set?. However, I will look into qdev conversion of the PC RTC.

Thinking further: Is there a way to discover the available qdev device
parameters via the command line?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Markus Armbruster]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Thinking further: Is there a way to discover the available qdev device
> parameters via the command line?

Not that I know of.  Sounds quite feasible.

Monitor command "info qdm" and command line switch "-device \?" list
available devices.  Make "info qdm DEVNAME" list device properties?

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> You get most of this pretty cheaply with qdev conversion.  If you give
>> the rtc a default id, you can tweak all of the properties with the -set
>> command line option.  It also provides a mechanism to change the default
>> properties between machine types/versions which is ideal as we can
>> introduce a kvm-specific machine type where we enable some of these
>> things by default.
>>
>>     
>
> Hmm, the refactoring of the old command line switches to -rtc is, if I
> understand qdev and -set correctly, widely orthogonal.

No, it isn't.  To introduce -rtc properly, you should use QemuOpts.  We 
shouldn't be introducing new options that don't conform to QemuOpts 
syntax and the best way to do that is to just use QemuOpts.

To communicate the QemuOpts to the rtc, I think the easiest approach is 
to convert rtc to qdev and reuse the -device logic.  Otherwise, you have 
to use statics or add new parameters to the machine init.

>  Or is the policy
> now to freeze all command line switches in favor of the -device and
> -set?.

As much as possible, yes, I think this is the reasonable thing to do.

>  However, I will look into qdev conversion of the PC RTC.
>
> Besides the interface thing, I'm also interesting in comments on the
> other core idea, the selectable RTC base clock. Do we want this knob? Do
> we want host_clock unconditionally? Or should the other RTC that
> currently use the host time already also gain vm_clock support over the
> time?
>   
Hard to say.  Doesn't the rtc keep track of wallclock time even on power 
off?  I think using host_clock unconditionally does actually make sense.

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

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

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> You get most of this pretty cheaply with qdev conversion.  If you give
>>> the rtc a default id, you can tweak all of the properties with the -set
>>> command line option.  It also provides a mechanism to change the default
>>> properties between machine types/versions which is ideal as we can
>>> introduce a kvm-specific machine type where we enable some of these
>>> things by default.
>>>
>>>     
>>
>> Hmm, the refactoring of the old command line switches to -rtc is, if I
>> understand qdev and -set correctly, widely orthogonal.
> 
> No, it isn't.  To introduce -rtc properly, you should use QemuOpts.  We
> shouldn't be introducing new options that don't conform to QemuOpts
> syntax and the best way to do that is to just use QemuOpts.

Yes, QemuOpts is a must-have for -rtc. So you agree to introduce -rtc
(in addition to the qdev-based configuration, of course)?

> 
> To communicate the QemuOpts to the rtc, I think the easiest approach is
> to convert rtc to qdev and reuse the -device logic.  Otherwise, you have
> to use statics or add new parameters to the machine init.

Agreed. And Gerd obviously already did that work for me. :)

> 
>>  Or is the policy
>> now to freeze all command line switches in favor of the -device and
>> -set?.
> 
> As much as possible, yes, I think this is the reasonable thing to do.
> 
>>  However, I will look into qdev conversion of the PC RTC.
>>
>> Besides the interface thing, I'm also interesting in comments on the
>> other core idea, the selectable RTC base clock. Do we want this knob? Do
>> we want host_clock unconditionally? Or should the other RTC that
>> currently use the host time already also gain vm_clock support over the
>> time?
>>   
> Hard to say.  Doesn't the rtc keep track of wallclock time even on power
> off?  I think using host_clock unconditionally does actually make sense.
> 

Moreover, quite a few (of not all?) other RTCs use the host time
already. Well, I would be happy to avoid that 'clock' knob. So if there
are no concerns, I will unconditionally switch MC146818 to host_clock.

Jan


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

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> No, it isn't.  To introduce -rtc properly, you should use QemuOpts.  We
>> shouldn't be introducing new options that don't conform to QemuOpts
>> syntax and the best way to do that is to just use QemuOpts.
>>     
>
> Yes, QemuOpts is a must-have for -rtc. So you agree to introduce -rtc
> (in addition to the qdev-based configuration, of course)?
>   

Yup.

  

>> Hard to say.  Doesn't the rtc keep track of wallclock time even on power
>> off?  I think using host_clock unconditionally does actually make sense.
>>
>>     
>
> Moreover, quite a few (of not all?) other RTCs use the host time
> already. Well, I would be happy to avoid that 'clock' knob. So if there
> are no concerns, I will unconditionally switch MC146818 to host_clock.
>   

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jamie Lokier]

Anthony Liguori wrote:
> >Besides the interface thing, I'm also interesting in comments on the
> >other core idea, the selectable RTC base clock. Do we want this knob? Do
> >we want host_clock unconditionally? Or should the other RTC that
> >currently use the host time already also gain vm_clock support over the
> >time?
> >  
> Hard to say.  Doesn't the rtc keep track of wallclock time even on power 
> off?  I think using host_clock unconditionally does actually make sense.

Sometimes it's useful to offset the emulated clock for one reason or
another, hence the -startdate options.  But having it run at the
correct speed is usually useful :-)

Also, sometimes (due to licenses with wallclock limits) it's useful
for a guest to not see much time pass when the guest is powered off,
although it still needs to be positive.

Will the -startdate functionality be maintained with the RTC changes?

-- Jamie

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>>> Besides the interface thing, I'm also interesting in comments on the
>>> other core idea, the selectable RTC base clock. Do we want this knob? Do
>>> we want host_clock unconditionally? Or should the other RTC that
>>> currently use the host time already also gain vm_clock support over the
>>> time?
>>>  
>> Hard to say.  Doesn't the rtc keep track of wallclock time even on power 
>> off?  I think using host_clock unconditionally does actually make sense.
> 
> Sometimes it's useful to offset the emulated clock for one reason or
> another, hence the -startdate options.  But having it run at the
> correct speed is usually useful :-)

Indeed.

> 
> Also, sometimes (due to licenses with wallclock limits) it's useful
> for a guest to not see much time pass when the guest is powered off,
> although it still needs to be positive.

I'm not sure if this is a common use case. And it currently only seems
to be support by very few RTCs, the MC146818 being the most prominent one.

I'm now a fan of converting the latter to the common scheme of using the
host's system time (here via host_clock) and watch out for the need of
adding -rtc clock=vm.

> 
> Will the -startdate functionality be maintained with the RTC changes?

Yes, just like -localtime, this will still be supported of course.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Dor Laor]

On 09/11/2009 11:54 AM, Jan Kiszka wrote:
> Jamie Lokier wrote:
>> Anthony Liguori wrote:
>>>> Besides the interface thing, I'm also interesting in comments on the
>>>> other core idea, the selectable RTC base clock. Do we want this knob? Do
>>>> we want host_clock unconditionally? Or should the other RTC that
>>>> currently use the host time already also gain vm_clock support over the
>>>> time?
>>>>
>>> Hard to say.  Doesn't the rtc keep track of wallclock time even on power
>>> off?  I think using host_clock unconditionally does actually make sense.
>>
>> Sometimes it's useful to offset the emulated clock for one reason or
>> another, hence the -startdate options.  But having it run at the
>> correct speed is usually useful :-)
>
> Indeed.
>
>>
>> Also, sometimes (due to licenses with wallclock limits) it's useful
>> for a guest to not see much time pass when the guest is powered off,
>> although it still needs to be positive.
>
> I'm not sure if this is a common use case. And it currently only seems
> to be support by very few RTCs, the MC146818 being the most prominent one.
>
> I'm now a fan of converting the latter to the common scheme of using the
> host's system time (here via host_clock) and watch out for the need of
> adding -rtc clock=vm.

I'm in favor of sticking to clock=vm as a default.
Most chances that the guest will have internet connect and the host (ala 
rom hypervisor) won't have.
Furthermore, if the guest and the host are running ntp it might cause 
spurious ntp updates by the guest. Also on migration, you need to make 
sure that both src and dst are synchronized. When using clock=vm there 
is no such need.

Is the only case that clock=host is preferred is when the guest does not 
run ntp while the host does?

>
>>
>> Will the -startdate functionality be maintained with the RTC changes?
>
> Yes, just like -localtime, this will still be supported of course.

btw: -startdate is good when the host and the guest use different TZs.

>
> Jan
>

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

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

Dor Laor wrote:
> On 09/11/2009 11:54 AM, Jan Kiszka wrote:
>> Jamie Lokier wrote:
>>> Anthony Liguori wrote:
>>>>> Besides the interface thing, I'm also interesting in comments on the
>>>>> other core idea, the selectable RTC base clock. Do we want this
>>>>> knob? Do
>>>>> we want host_clock unconditionally? Or should the other RTC that
>>>>> currently use the host time already also gain vm_clock support over
>>>>> the
>>>>> time?
>>>>>
>>>> Hard to say.  Doesn't the rtc keep track of wallclock time even on
>>>> power
>>>> off?  I think using host_clock unconditionally does actually make
>>>> sense.
>>>
>>> Sometimes it's useful to offset the emulated clock for one reason or
>>> another, hence the -startdate options.  But having it run at the
>>> correct speed is usually useful :-)
>>
>> Indeed.
>>
>>>
>>> Also, sometimes (due to licenses with wallclock limits) it's useful
>>> for a guest to not see much time pass when the guest is powered off,
>>> although it still needs to be positive.
>>
>> I'm not sure if this is a common use case. And it currently only seems
>> to be support by very few RTCs, the MC146818 being the most prominent
>> one.
>>
>> I'm now a fan of converting the latter to the common scheme of using the
>> host's system time (here via host_clock) and watch out for the need of
>> adding -rtc clock=vm.
> 
> I'm in favor of sticking to clock=vm as a default.
> Most chances that the guest will have internet connect and the host (ala
> rom hypervisor) won't have.
> Furthermore, if the guest and the host are running ntp it might cause
> spurious ntp updates by the guest. Also on migration, you need to make
> sure that both src and dst are synchronized. When using clock=vm there
> is no such need.

clock=vm means that the RTC has no use as a reliable clock source, you
always need additional help by NTP etc. in the guest -- unless you don't
care about accurate time, of course.

Note that, if you don't trust the virtual RTC (e.g. because it's driven
by an isolated hypervisor) and you have NTP at hand, you typically
configure the guest to update the RTC according to NTP. Then migration
between two potentially unsynchronized hosts is also a none-issue.

> 
> Is the only case that clock=host is preferred is when the guest does not
> run ntp while the host does?

It is currently a must-have if you want to synchronize host and guest
clock (independent of the timezone) while NTP-like services are not an
option. This includes the case where none of both have NTP access.

Except for Jamie's case of extending some license runtime, I really see
no real use for RTC based on vm_clock anymore. There is some reason why
other RTCs are already based on the host clock.

Jan


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

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Anthony Liguori]

Jan Kiszka wrote:
> Dor Laor wrote:
>   
>> I'm in favor of sticking to clock=vm as a default.
>> Most chances that the guest will have internet connect and the host (ala
>> rom hypervisor) won't have.
>>     

Default behaviors only really matter for unmanaged environments.  An 
isolated hypervisor in a rom is most certainly a managed environment.  
As long as there is the ability to do clock=vm, setting clock=host by 
default should be fine.

> Except for Jamie's case of extending some license runtime, I really see
> no real use for RTC based on vm_clock anymore. There is some reason why
> other RTCs are already based on the host clock.
>   

In general, behaving like real hardware by default and supporting odd 
use-cases with additional options seems like a good policy to me.

> Jan
>   


-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

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

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Dor Laor wrote:
>>  
>>> I'm in favor of sticking to clock=vm as a default.
>>> Most chances that the guest will have internet connect and the host (ala
>>> rom hypervisor) won't have.
>>>     
> 
> Default behaviors only really matter for unmanaged environments.  An
> isolated hypervisor in a rom is most certainly a managed environment. 
> As long as there is the ability to do clock=vm, setting clock=host by
> default should be fine.

I still do not get why we need clock=vm here...

> 
>> Except for Jamie's case of extending some license runtime, I really see
>> no real use for RTC based on vm_clock anymore. There is some reason why
>> other RTCs are already based on the host clock.
>>   
> 
> In general, behaving like real hardware by default and supporting odd
> use-cases with additional options seems like a good policy to me.
> 

...but if this case shall be covered, I'm going to respin my series and
add the config switch. (I was just hoping to get a round it.)

Jan


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

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Markus Armbruster]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Anthony Liguori wrote:
>> Jan Kiszka wrote:
>>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>>> as a reliable time source for guests. This is particularly useful if the
>>> host runs NTP or has otherwise access to an accurate clock while the
>>> guest has not (no network, impossible to add an NTP implementation
>>> etc.).
>>>
>>> To achieve this, the command line switch -rtc is introduced. It takes
>>> the option 'clock' to switch between the currently used base ('vm') and
>>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
>>> deprecate all the other RTC-related stand-alone switches.
>>>
>>> First tests indicate that this approach works as expected and could
>>> increase the usefulness of the virtual RTC enormously. However, there
>>> might be pitfalls I've missed so far. Feedback would be welcome!
>>>   
>> 
>> You get most of this pretty cheaply with qdev conversion.  If you give
>> the rtc a default id, you can tweak all of the properties with the -set
>> command line option.  It also provides a mechanism to change the default
>> properties between machine types/versions which is ideal as we can
>> introduce a kvm-specific machine type where we enable some of these
>> things by default.
>> 
>
> Hmm, the refactoring of the old command line switches to -rtc is, if I
> understand qdev and -set correctly, widely orthogonal. Or is the policy
> now to freeze all command line switches in favor of the -device and
> -set?. However, I will look into qdev conversion of the PC RTC.

Check out Gerd's conversion:

    From: Gerd Hoffmann <kraxel@redhat.com>
    To: qemu-devel@nongnu.org
    Date: Wed,  9 Sep 2009 16:45:47 +0200
    Message-Id: <1252507547-11398-13-git-send-email-kraxel@redhat.com>
    Subject: [Qemu-devel] [PATCH 12/12] qdev/isa: convert real time clock

[...]

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Gerd Hoffmann]

On 09/09/09 17:40, Anthony Liguori wrote:
> Jan Kiszka wrote:
>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>> as a reliable time source for guests. This is particularly useful if the
>> host runs NTP or has otherwise access to an accurate clock while the
>> guest has not (no network, impossible to add an NTP implementation
>> etc.).
>>
>> To achieve this, the command line switch -rtc is introduced. It takes
>> the option 'clock' to switch between the currently used base ('vm') and
>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
>> deprecate all the other RTC-related stand-alone switches.
>>
>> First tests indicate that this approach works as expected and could
>> increase the usefulness of the virtual RTC enormously. However, there
>> might be pitfalls I've missed so far. Feedback would be welcome!
>
> You get most of this pretty cheaply with qdev conversion. If you give
> the rtc a default id, you can tweak all of the properties with the -set
> command line option.

It isn't that simple.  -set device.$id.$property=$value works only for 
devices actually created via -device.

cheers,
   Gerd

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Blue Swirl]

On Wed, Sep 9, 2009 at 6:11 PM, Jan Kiszka<jan.kiszka@web.de> wrote:
> The aim of this series is to allow using the emulated PC RTC (MC146818)
> as a reliable time source for guests. This is particularly useful if the
> host runs NTP or has otherwise access to an accurate clock while the
> guest has not (no network, impossible to add an NTP implementation
> etc.).

What I meant in the earlier thread is that m48t59 port read for time
or date gets the data directly from host using  qemu_get_timedate().
PC RTC instead uses a timer: the timer callback updates the cmos_data
structure. It seems that you just replace the timer with a new one.
I'd remove the timer altogether and change the cmos_ioport_read to
call qemu_get_timedate().

[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka]

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

Blue Swirl wrote:
> On Wed, Sep 9, 2009 at 6:11 PM, Jan Kiszka<jan.kiszka@web.de> wrote:
>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>> as a reliable time source for guests. This is particularly useful if the
>> host runs NTP or has otherwise access to an accurate clock while the
>> guest has not (no network, impossible to add an NTP implementation
>> etc.).
> 
> What I meant in the earlier thread is that m48t59 port read for time
> or date gets the data directly from host using  qemu_get_timedate().
> PC RTC instead uses a timer: the timer callback updates the cmos_data
> structure. It seems that you just replace the timer with a new one.
> I'd remove the timer altogether and change the cmos_ioport_read to
> call qemu_get_timedate().

That was my first idea as well, but the timer is there to emulate real
hardware behavior: Updates only take place while the UIP flag is set in
register A, and they take a few hundred microseconds. Guests actually
wait for this to happen and only read out after such a change. Moreover,
updates can trigger interrupts.

For sure one could avoid these update timers. But as they are so rare (1
HZ...), I didn't want to prematurely optimize the code here, risking
regressions while trying to fix our problems.

Jan


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