This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] xend: fix rtc_timeoffset when localtime=1

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xend: fix rtc_timeoffset when localtime=1
From: Kouya Shimura <kouya@xxxxxxxxxxxxxx>
Date: Thu, 2 Apr 2009 14:24:02 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 01 Apr 2009 22:24:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18899.37002.688166.445055@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <7ky6uk6c8y.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <18899.37002.688166.445055@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Ian Jackson writes:
> Kouya Shimura writes ("[Xen-devel] [PATCH] xend: fix rtc_timeoffset when 
> localtime=1"):
> > The rtc_timeoffset parameter in VM config is ignored when localtime=1.
> > Also it is not preserved across reboot.
> > 
> > NOTE:
> > This patch changes the meaning of the xenstore /vm/<uuid>/rtc/timeoffset
> > from utc offset to local offset. (it's OK for the ioemu)
> Are you sure that this is an appropriate change ?  I'm not sure I
> follow exactly and have only skimread your patch.  Can you explain why
> it is right to change the meaning of a xenstore value like this ?

Hi Ian,

I'm quite sure. From a ioemu point of view, the value is no concern
of the ioemu. The ioemu receives the ioreq, accumulates the value,
and then just passes it to the xenstore. 
You can apply the attached patch. :-)

When a guest changes the real time clock, the hypervisor sends the
difference between before and after via ioreq to the ioemu.
see rtc_set_time@xen/arch/x86/hvm/rtc.c.
Thus, /rtc/timeoffset keeps correct offset from any initial value.

And xend is the only one to refer /rtc/timeoffset, and xend knows
that it is a offset based on local time. So, my scheme works well.

In addition, PV domain doesn't use the xenstore /rtc/timeoffset.


Signed-off-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx>

diff --git a/hw/xen_machine_fv.c b/hw/xen_machine_fv.c
index 9bca50a..a2ca3e7 100644
--- a/hw/xen_machine_fv.c
+++ b/hw/xen_machine_fv.c
@@ -276,9 +276,6 @@ static void xen_init_fv(ram_addr_t ram_size, int 
-    timeoffset_get();
     pc_machine.init(ram_size, vga_ram_size, boot_device,
                    kernel_filename, kernel_cmdline, initrd_filename,
                    cpu_model, direct_pci);
diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 969241f..d95cfc9 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -91,7 +91,8 @@ int domid_backend = 0;
    * domain case.
-long time_offset = 0;
+static long time_offset = 0;
+static void timeoffset_get(void);
 shared_iopage_t *shared_page = NULL;
@@ -146,6 +147,8 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
             ioreq_local_port[i] = rc;
+        timeoffset_get();
     return env;
@@ -402,7 +405,7 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
-void timeoffset_get(void)
+static void timeoffset_get(void)
     char *p;
diff --git a/qemu-xen.h b/qemu-xen.h
index ec4cd94..9d4642d 100644
--- a/qemu-xen.h
+++ b/qemu-xen.h
@@ -18,10 +18,6 @@ void     qemu_invalidate_map_cache(void);
 #define mapcache_lock()   ((void)0)
 #define mapcache_unlock() ((void)0)
-/* helper2.c */
-extern long time_offset;
-void timeoffset_get(void);
 /* xen_platform.c */
 #ifndef QEMU_TOOL
 void pci_xen_platform_init(PCIBus *bus);
Xen-devel mailing list