RE: wallclock time for paravirtualized guests

RE: wallclock time for paravirtualized guests

[Ian Pratt]

> The paravirtualized guests are offered wallclock time 
> referenced to UTC only, while fully virtualized guests are 
> given the option via the config file (localtime parameter) of 
> starting with UTC time or local time.
> What would it take to optionally provide localtime to the 
> paravirtualized guests as well?
> For a guest that launches assuming localtime as its time 
> basis, then later deriving UTC from it based on configuration 
> files, this is problematic, requiring some convolutions to 
> how it handles time as it boots.
> Is there some place where we can insert a localtime offset 
> into the start-of-day structure, or perhaps change the 
> sharedinfo wallclock time to be either localtime or utc, 
> depending on a localtime parameter in the config file, 
> similar to what is done for fully virtualized guests?

I guess it might be useful to be able to configure a 'wallclock offset
in seconds' for a domain. It would need to be implemented in Xen and set
via a dom0 op.

Ian 

RE: wallclock time for paravirtualized guests

[Bruce Rogers]

[-- Attachment #1.1: Type: text/plain, Size: 1376 bytes --]

I'll see about putting together a patch then.
Is it OK to simply have wc_sec altered by an optional, per domain time
offset from UTC in seconds (hence binary no change to the interface), or
do you think there should be another field provided that is the offset,
leaving wc_sec unmodified?
 
- Bruce Rogers

>>> "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> 3/27/2006 8:40:16 pm >>>
> The paravirtualized guests are offered wallclock time 
> referenced to UTC only, while fully virtualized guests are 
> given the option via the config file (localtime parameter) of 
> starting with UTC time or local time.
> What would it take to optionally provide localtime to the 
> paravirtualized guests as well?
> For a guest that launches assuming localtime as its time 
> basis, then later deriving UTC from it based on configuration 
> files, this is problematic, requiring some convolutions to 
> how it handles time as it boots.
> Is there some place where we can insert a localtime offset 
> into the start-of-day structure, or perhaps change the 
> sharedinfo wallclock time to be either localtime or utc, 
> depending on a localtime parameter in the config file, 
> similar to what is done for fully virtualized guests?

I guess it might be useful to be able to configure a 'wallclock offset
in seconds' for a domain. It would need to be implemented in Xen and
set
via a dom0 op.

Ian 

[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 1781 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: wallclock time for paravirtualized guests

[Keir Fraser]

On 28 Mar 2006, at 16:28, Bruce Rogers wrote:

> I'll see about putting together a patch then.
> Is it OK to simply have wc_sec altered by an optional, per domain time 
> offset from UTC in seconds (hence binary no change to the interface), 
> or do you think there should be another field provided that is the 
> offset, leaving wc_sec unmodified?

The former. No need to change the guest ABI.

  -- Keir

[PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

[-- Attachment #1.1: Type: text/plain, Size: 292 bytes --]

This patch allows the localtime parameter to be used for
para-virtualized guests.
Some paravirtualized guests may need to start with a local time basis
instead of UTC.
This patch provides for that need.  Please review and apply.
 
Thank you
 
Signed-off-by: Bruce Rogers <brogers@novell.com>

[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 651 bytes --]

[-- Attachment #2: localtime.patch --]
[-- Type: application/octet-stream, Size: 7211 bytes --]

diff -r 85b7a341207e tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Mar 30 13:06:11 2006
+++ b/tools/libxc/xc_domain.c	Fri Mar 31 13:18:41 2006
@@ -257,6 +257,17 @@
     return do_dom0_op(xc_handle, &op);
 }
 
+int xc_domain_set_time_offset(int xc_handle,
+                              uint32_t domid, 
+                              int32_t time_offset_seconds)
+{
+    DECLARE_DOM0_OP;
+    op.cmd = DOM0_SETTIMEOFFSET;
+    op.u.settimeoffset.domain = (domid_t)domid;
+    op.u.settimeoffset.time_offset_seconds = time_offset_seconds;
+    return do_dom0_op(xc_handle, &op);
+}
+
 int xc_domain_memory_increase_reservation(int xc_handle,
                                           uint32_t domid, 
                                           unsigned long nr_extents,
diff -r 85b7a341207e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Mar 30 13:06:11 2006
+++ b/tools/libxc/xenctrl.h	Fri Mar 31 13:18:41 2006
@@ -385,6 +385,10 @@
                         uint32_t domid, 
                         unsigned int max_memkb);
 
+int xc_domain_set_time_offset(int xc_handle,
+                              uint32_t domid, 
+                              int32_t time_offset_seconds);
+
 int xc_domain_memory_increase_reservation(int xc_handle,
                                           uint32_t domid, 
                                           unsigned long nr_extents,
diff -r 85b7a341207e tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Thu Mar 30 13:06:11 2006
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Mar 31 13:18:41 2006
@@ -826,6 +826,19 @@
     return zero;
 }
 
+static PyObject *pyxc_domain_set_time_offset(XcObject *self, PyObject *args)
+{
+    uint32_t dom;
+    int32_t time_offset_seconds;
+
+    if (!PyArg_ParseTuple(args, "i", &dom))
+        return NULL;
+
+    time_offset_seconds = -__timezone;
+    if (xc_domain_set_time_offset(self->xc_handle, dom, time_offset_seconds) != 0)
+        return NULL;
+    return zero;
+}
 
 static PyObject *dom_op(XcObject *self, PyObject *args,
                         int (*fn)(int, uint32_t))
@@ -1146,6 +1159,13 @@
       METH_VARARGS, "\n"
       "Returns: [int]: The size in KiB of memory spanning the given number "
       "of pages.\n" },
+
+    { "domain_set_time_offset", 
+      (PyCFunction)pyxc_domain_set_time_offset, 
+      METH_VARARGS, "\n"
+      "Set a domain's time offset to Dom0's localtime\n"
+      " dom        [int]: Domain whose time offset is being set.\n"
+      "Returns: [int] 0 on success; -1 on error.\n" },
 
     { NULL, NULL, 0, NULL }
 };
diff -r 85b7a341207e tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py	Thu Mar 30 13:06:11 2006
+++ b/tools/python/xen/xend/XendDomainInfo.py	Fri Mar 31 13:18:41 2006
@@ -127,6 +127,7 @@
     ('memory',     int),
     ('maxmem',     int),
     ('bootloader', str),
+    ('localtime',  str),
     ]
 
 ROUNDTRIPPING_CONFIG_ENTRIES += VM_CONFIG_PARAMS
@@ -1203,6 +1204,10 @@
                                       self.info['image'],
                                       self.info['device'])
 
+            localtime = self.info['localtime']
+            if localtime is not None and localtime == 'yes':
+                xc.domain_set_time_offset(self.domid)
+
             xc.domain_setcpuweight(self.domid, self.info['cpu_weight'])
 
             # repin domain vcpus if a restricted cpus list is provided
diff -r 85b7a341207e tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py	Thu Mar 30 13:06:11 2006
+++ b/tools/python/xen/xm/create.py	Fri Mar 31 13:18:41 2006
@@ -610,6 +610,8 @@
         config.append(['backend', ['netif']])
     if vals.tpmif:
         config.append(['backend', ['tpmif']])
+    if vals.localtime:
+        config.append(['localtime', vals.localtime])
 
     if vals.bootloader:
         config.append(['bootloader', vals.bootloader])
diff -r 85b7a341207e xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Mar 30 13:06:11 2006
+++ b/xen/arch/x86/time.c	Fri Mar 31 13:18:41 2006
@@ -716,7 +716,7 @@
     {
         s = d->shared_info;
         version_update_begin(&s->wc_version);
-        s->wc_sec  = _wc_sec;
+        s->wc_sec  = _wc_sec + d->time_offset_seconds;
         s->wc_nsec = _wc_nsec;
         version_update_end(&s->wc_version);
     }
@@ -725,11 +725,21 @@
     read_unlock(&domlist_lock);
 }
 
+void do_settimeoffset(struct domain *d, int32_t time_offset_seconds)
+{
+    shared_info_t *s;
+
+    s = d->shared_info;
+    version_update_begin(&s->wc_version);
+    d->time_offset_seconds = time_offset_seconds;
+    version_update_end(&s->wc_version);
+}
+
 void init_domain_time(struct domain *d)
 {
     spin_lock(&wc_lock);
     version_update_begin(&d->shared_info->wc_version);
-    d->shared_info->wc_sec  = wc_sec;
+    d->shared_info->wc_sec  = wc_sec + d->time_offset_seconds;
     d->shared_info->wc_nsec = wc_nsec;
     version_update_end(&d->shared_info->wc_version);
     spin_unlock(&wc_lock);
diff -r 85b7a341207e xen/common/dom0_ops.c
--- a/xen/common/dom0_ops.c	Thu Mar 30 13:06:11 2006
+++ b/xen/common/dom0_ops.c	Fri Mar 31 13:18:42 2006
@@ -682,6 +682,20 @@
     break;
 #endif
 
+    case DOM0_SETTIMEOFFSET:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = find_domain_by_id(op->u.settimeoffset.domain);
+        if ( d != NULL )
+        {
+            do_settimeoffset(d, op->u.settimeoffset.time_offset_seconds);
+            ret = 0;
+        }
+    }
+    break;
+
     default:
         ret = arch_do_dom0_op(op, u_dom0_op);
         break;
diff -r 85b7a341207e xen/include/public/dom0_ops.h
--- a/xen/include/public/dom0_ops.h	Thu Mar 30 13:06:11 2006
+++ b/xen/include/public/dom0_ops.h	Fri Mar 31 13:18:42 2006
@@ -470,6 +470,12 @@
     unsigned long mfn;        /* machine frame to be initialised */
 } dom0_hypercall_init_t;
 DEFINE_GUEST_HANDLE(dom0_hypercall_init_t);
+
+#define DOM0_SETTIMEOFFSET    49
+typedef struct dom0_settimeoffset {
+    domid_t  domain;
+    int32_t  time_offset_seconds; /* applied to domain wallclock time */ 
+} dom0_settimeoffset_t;
 
 typedef struct dom0_op {
     uint32_t cmd;
@@ -512,6 +518,7 @@
         struct dom0_irq_permission    irq_permission;
         struct dom0_iomem_permission  iomem_permission;
         struct dom0_hypercall_init    hypercall_init;
+        struct dom0_settimeoffset     settimeoffset;
         uint8_t                       pad[128];
     } u;
 } dom0_op_t;
diff -r 85b7a341207e xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Thu Mar 30 13:06:11 2006
+++ b/xen/include/xen/sched.h	Fri Mar 31 13:18:42 2006
@@ -155,6 +155,7 @@
 
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
+    s32              time_offset_seconds;
 };
 
 struct domain_setup_info
diff -r 85b7a341207e xen/include/xen/time.h
--- a/xen/include/xen/time.h	Thu Mar 30 13:06:11 2006
+++ b/xen/include/xen/time.h	Fri Mar 31 13:18:42 2006
@@ -59,6 +59,7 @@
 extern void do_settime(
     unsigned long secs, unsigned long nsecs, u64 system_time_base);
 
+extern void do_settimeoffset(struct domain *d, int32_t wc_offset);
 extern void send_timer_event(struct vcpu *v);
 
 #endif /* __XEN_TIME_H__ */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Muli Ben-Yehuda]

On Fri, Mar 31, 2006 at 03:22:50PM -0500, Bruce Rogers wrote:

> This patch allows the localtime parameter to be used for
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis
> instead of UTC.
> This patch provides for that need.  Please review and apply.

Why is this functionality needed? what is the equivalent when running
on bare metal?

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

Re: [PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

[-- Attachment #1.1: Type: text/plain, Size: 843 bytes --]

Some para-virtualized OS's (eg. NetWare) assume they are starting from a
localtime time base, and our start-of-day time information should allow
such a guest to work without gross modifications.  Xen already make such
an allowance for fully virtualized guests.  This is just closing the
gap.
 
- Bruce


>>> Muli Ben-Yehuda <mulix@mulix.org> 3/31/2006 1:30:47 pm >>>
On Fri, Mar 31, 2006 at 03:22:50PM -0500, Bruce Rogers wrote:

> This patch allows the localtime parameter to be used for
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time
basis
> instead of UTC.
> This patch provides for that need.  Please review and apply.

Why is this functionality needed? what is the equivalent when running
on bare metal?

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 1219 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Keir Fraser]

On 31 Mar 2006, at 21:22, Bruce Rogers wrote:

> This patch allows the localtime parameter to be used for 
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis 
> instead of UTC.
> This patch provides for that need.  Please review and apply.

I've just checked in a patch to provide a clean wallclock update 
interface from common Xen code. Please re-send based on that patch. 
Your dom0_op implementation should modify d->time_offset_seconds 
directly and then call update_domain_wallclock_time(d).

Apart from that, the time_offset_seconds field in dom0_op.h should be 
type int32_t (we don't use s32 in public headers).

  -- Keir

Re: [PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

Thanks.  I'll resend then.  I did notice a few issues with my original
patch, so it good that it's getting looked at in greater detail.

- Bruce

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 4/5/2006 7:03:50 am >>>

On 31 Mar 2006, at 21:22, Bruce Rogers wrote:

> This patch allows the localtime parameter to be used for 
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis

> instead of UTC.
> This patch provides for that need.  Please review and apply.

I've just checked in a patch to provide a clean wallclock update 
interface from common Xen code. Please re-send based on that patch. 
Your dom0_op implementation should modify d->time_offset_seconds 
directly and then call update_domain_wallclock_time(d).

Apart from that, the time_offset_seconds field in dom0_op.h should be 
type int32_t (we don't use s32 in public headers).

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com 
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

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

Attached please find a patch (against unstable tree) which provides
some localtime support for paravirtualized guests.  It is quite
minimal
in its approach, satisfying the purposes of the paravirtualized
NetWare operating system as well as any others that expect the time
base to be provided in localtime.

I should point out however that this by itself does not allow a
localtime
time base to be used for xenolinux.  That support would require
additional
changes to Linux (eg a Xen aware implementation of /dev/rtc & etc.),
and
should probably be based on a more flexible and thorough implementation
of
non-UTC guest time bases than what this patch provides.  Nevertheless,
this patch is functionaly equivalent to what is being done SLES 10's
Xen
implementation (but with SLES10 being based on testing tree), so I felt
it
should be submitted as is, with a more comprehensive approach
submitted
separately.

Signed-off-by: Bruce Rogers <brogers@novell.com>

- Bruce

>>> On 4/5/2006 at 8:03 AM, in message
<268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:

> On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> 
>> This patch allows the localtime parameter to be used for 
>> para-virtualized guests.
>> Some paravirtualized guests may need to start with a local time
basis 
>> instead of UTC.
>> This patch provides for that need.  Please review and apply.
> 
> I've just checked in a patch to provide a clean wallclock update 
> interface from common Xen code. Please re-send based on that patch. 
> Your dom0_op implementation should modify d->time_offset_seconds 
> directly and then call update_domain_wallclock_time(d).
> 
> Apart from that, the time_offset_seconds field in dom0_op.h should be

> type int32_t (we don't use s32 in public headers).
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel

[-- Attachment #2: xen-localtime.diff --]
[-- Type: application/octet-stream, Size: 6168 bytes --]

--- xen-unstable.orig/tools/libxc/xc_domain.c
+++ xen-unstable/tools/libxc/xc_domain.c
@@ -286,6 +286,17 @@ int xc_domain_setmaxmem(int xc_handle,
     return do_dom0_op(xc_handle, &op);
 }
 
+int xc_domain_set_time_offset(int xc_handle,
+                              uint32_t domid,
+                              int32_t time_offset_seconds)
+{
+    DECLARE_DOM0_OP;
+    op.cmd = DOM0_SETTIMEOFFSET;
+    op.u.settimeoffset.domain = (domid_t)domid;
+    op.u.settimeoffset.time_offset_seconds = time_offset_seconds;
+    return do_dom0_op(xc_handle, &op);
+}
+
 int xc_domain_memory_increase_reservation(int xc_handle,
                                           uint32_t domid,
                                           unsigned long nr_extents,
--- xen-unstable.orig/tools/libxc/xenctrl.h
+++ xen-unstable/tools/libxc/xenctrl.h
@@ -410,6 +410,10 @@ int xc_domain_setmaxmem(int xc_handle,
                         uint32_t domid,
                         unsigned int max_memkb);
 
+int xc_domain_set_time_offset(int xc_handle,
+                              uint32_t domid,
+                              int32_t time_offset_seconds);
+
 int xc_domain_memory_increase_reservation(int xc_handle,
                                           uint32_t domid,
                                           unsigned long nr_extents,
--- xen-unstable.orig/tools/python/xen/xend/XendDomainInfo.py
+++ xen-unstable/tools/python/xen/xend/XendDomainInfo.py
@@ -135,6 +135,7 @@
     ('bootloader', str),
     ('bootloader_args', str),
     ('features', str),
+    ('localtime', int),
     ]
 
 ROUNDTRIPPING_CONFIG_ENTRIES += VM_CONFIG_PARAMS
@@ -1260,6 +1261,10 @@
                                       self.info['image'],
                                       self.info['device'])
 
+            localtime = self.info['localtime']
+            if localtime is not None and localtime == 1:
+                xc.domain_set_time_offset(self.domid)
+
             xc.domain_setcpuweight(self.domid, self.info['cpu_weight'])
 
             # repin domain vcpus if a restricted cpus list is provided
--- xen-unstable.orig/tools/python/xen/xm/create.py
+++ xen-unstable/tools/python/xen/xm/create.py
@@ -672,6 +672,8 @@
         config.append(['backend', ['netif']])
     if vals.tpmif:
         config.append(['backend', ['tpmif']])
+    if vals.localtime:
+        config.append(['localtime', vals.localtime])
 
     config_image = configure_image(vals)
     if vals.bootloader:
--- xen-unstable.orig/xen/arch/x86/time.c
+++ xen-unstable/xen/arch/x86/time.c	
@@ -699,7 +699,7 @@
 {
     spin_lock(&wc_lock);
     version_update_begin(&d->shared_info->wc_version);
-    d->shared_info->wc_sec  = wc_sec;
+    d->shared_info->wc_sec  = wc_sec + d->time_offset_seconds;
     d->shared_info->wc_nsec = wc_nsec;
     version_update_end(&d->shared_info->wc_version);
     spin_unlock(&wc_lock);
--- xen-unstable.orig/xen/common/dom0_ops.c
+++ xen-unstable/xen/common/dom0_ops.c
@@ -693,6 +693,21 @@ long do_dom0_op(GUEST_HANDLE(dom0_op_t) 
     break;
 #endif
 
+    case DOM0_SETTIMEOFFSET:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = find_domain_by_id(op->u.settimeoffset.domain);
+        if ( d != NULL )
+        {
+            d->time_offset_seconds = op->u.settimeoffset.time_offset_seconds;
+            put_domain(d);
+            ret = 0;
+        }
+    }
+    break;
+
     default:
         ret = arch_do_dom0_op(op, u_dom0_op);
         break;
--- xen-unstable.orig/xen/include/public/dom0_ops.h
+++ xen-unstable/xen/include/public/dom0_ops.h
@@ -514,6 +514,14 @@
 typedef struct dom0_hypercall_init dom0_hypercall_init_t;
 DEFINE_XEN_GUEST_HANDLE(dom0_hypercall_init_t);
 
+#define DOM0_SETTIMEOFFSET    49
+struct dom0_settimeoffset {
+    domid_t  domain;
+    int32_t  time_offset_seconds; /* applied to domain wallclock time */
+};
+typedef struct dom0_settimeoffset dom0_settimeoffset_t;
+DEFINE_XEN_GUEST_HANDLE(dom0_settimeoffset_t);
+
 struct dom0_op {
     uint32_t cmd;
     uint32_t interface_version; /* DOM0_INTERFACE_VERSION */
@@ -555,6 +563,7 @@
         struct dom0_irq_permission    irq_permission;
         struct dom0_iomem_permission  iomem_permission;
         struct dom0_hypercall_init    hypercall_init;
+        struct dom0_settimeoffset     settimeoffset;
         uint8_t                       pad[128];
     } u;
 };
--- xen-unstable.orig/xen/include/xen/sched.h
+++ xen-unstable/xen/include/xen/sched.h
@@ -159,6 +159,7 @@
 
     /* OProfile support. */
     struct xenoprof *xenoprof;
+    int32_t time_offset_seconds;
 };
 
 struct domain_setup_info
--- xen-unstable.orig/tools/python/xen/lowlevel/xc/xc.c
+++ xen-unstable/tools/python/xen/lowlevel/xc/xc.c
@@ -869,6 +869,30 @@ static PyObject *pyxc_domain_iomem_permi
     return zero;
 }
 
+static PyObject *pyxc_domain_set_time_offset(XcObject *self, PyObject *args)
+{
+    uint32_t dom;
+    int32_t time_offset_seconds;
+    time_t calendar_time;
+    struct tm local_time;
+    struct tm utc_time;
+
+    if (!PyArg_ParseTuple(args, "i", &dom))
+        return NULL;
+
+    calendar_time = time(NULL);
+    localtime_r(&calendar_time, &local_time);
+    gmtime_r(&calendar_time, &utc_time);
+    /* set up to get calendar time based on utc_time, with local dst setting */
+    utc_time.tm_isdst = local_time.tm_isdst;
+    time_offset_seconds = (int32_t)difftime(calendar_time, mktime(&utc_time));
+
+    if (xc_domain_set_time_offset(self->xc_handle, dom, time_offset_seconds) != 0)
+        return NULL;
+
+    Py_INCREF(zero);
+    return zero;
+}
 
 static PyObject *dom_op(XcObject *self, PyObject *args,
                         int (*fn)(int, uint32_t))
@@ -1208,6 +1208,13 @@ static PyMethodDef pyxc_methods[] = {
       "Returns: [int]: The size in KiB of memory spanning the given number "
       "of pages.\n" },
 
+    { "domain_set_time_offset",
+      (PyCFunction)pyxc_domain_set_time_offset,
+      METH_VARARGS, "\n"
+      "Set a domain's time offset to Dom0's localtime\n"
+      " dom        [int]: Domain whose time offset is being set.\n"
+      "Returns: [int] 0 on success; -1 on error.\n" },
+
     { NULL, NULL, 0, NULL }
 };
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[B Thomas]

[-- Attachment #1.1: Type: text/plain, Size: 2955 bytes --]

Hi,

Two quick comments/questions come to mind upon seeing this patch:

- it appears possible to set/reset the time offset multiple times even while
the domain is running. Am I misreading the patch ?  Is this desirable ?

- this is a different mechanism than the one used to set time offsets for
fully virtualized guests. At the lowest levels, this is probably difficult
to avoid.  Higher up, though, it would be nice if this type of capability
didn't look/act and be controlled differently.  The differences between
fully and para virtualized systems should disappear the higher into the
control logic you go.  Were you able to give any thought on how to merge the
models ?

-b



On 6/20/06, Bruce Rogers <BROGERS@novell.com> wrote:
>
> Attached please find a patch (against unstable tree) which provides
> some localtime support for paravirtualized guests.  It is quite
> minimal
> in its approach, satisfying the purposes of the paravirtualized
> NetWare operating system as well as any others that expect the time
> base to be provided in localtime.
>
> I should point out however that this by itself does not allow a
> localtime
> time base to be used for xenolinux.  That support would require
> additional
> changes to Linux (eg a Xen aware implementation of /dev/rtc & etc.),
> and
> should probably be based on a more flexible and thorough implementation
> of
> non-UTC guest time bases than what this patch provides.  Nevertheless,
> this patch is functionaly equivalent to what is being done SLES 10's
> Xen
> implementation (but with SLES10 being based on testing tree), so I felt
> it
> should be submitted as is, with a more comprehensive approach
> submitted
> separately.
>
> Signed-off-by: Bruce Rogers <brogers@novell.com>
>
> - Bruce
>
> >>> On 4/5/2006 at 8:03 AM, in message
> <268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk>, Keir Fraser
> <Keir.Fraser@cl.cam.ac.uk> wrote:
>
> > On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> >
> >> This patch allows the localtime parameter to be used for
> >> para-virtualized guests.
> >> Some paravirtualized guests may need to start with a local time
> basis
> >> instead of UTC.
> >> This patch provides for that need.  Please review and apply.
> >
> > I've just checked in a patch to provide a clean wallclock update
> > interface from common Xen code. Please re-send based on that patch.
> > Your dom0_op implementation should modify d->time_offset_seconds
> > directly and then call update_domain_wallclock_time(d).
> >
> > Apart from that, the time_offset_seconds field in dom0_op.h should be
>
> > type int32_t (we don't use s32 in public headers).
> >
> >   -- Keir
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3903 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Keir Fraser]

On 21 Jun 2006, at 16:29, B Thomas wrote:

> Hi,
>
>  Two quick comments/questions come to mind upon seeing this patch:
>
>  - it appears possible to set/reset the time offset multiple times 
> even while the domain is running. Am I misreading the patch ?  Is this 
> desirable ?

Yes you can. No it probably isn't desirable, but the higher-level tools 
only call the lower-level command during domain initialisation. If they 
did call it at other times, it'd be up to them to sync with running 
guests somehow.

>  - this is a different mechanism than the one used to set time offsets 
> for fully virtualized guests. At the lowest levels, this is probably 
> difficult to avoid.  Higher up, though, it would be nice if this type 
> of capability didn't look/act and be controlled differently.  The 
> differences between fully and para virtualized systems should 
> disappear the higher into the control logic you go.  Were you able to 
> give any thought on how to merge the models ?

The 'support' for full-virt guests is *only* a qemu patch right now. No 
tools integration at all. Integration would have to be in xend, as it 
is xend which kicks off the qemu-dm process for HVM guests. Setting the 
'timeoffset' based on the localtime config option wouldn't be very 
hard, and would unify that new option across PV and HVM guests. Patches 
welcome (and moving the logic to work out what the time offset should 
be from xc.c into xend itself would be nice).

  -- Keir


>  -b
>
>
>
> On 6/20/06, Bruce Rogers <BROGERS@novell.com> wrote:
>> some localtime support for paravirtualized guests.  It is quite
>> minimal
>> in its approach, satisfying the purposes of the paravirtualized
>> NetWare operating system as well as any others that expect the time
>> base to be provided in localtime.
>>
>> I should point out however that this by itself does not allow a
>> localtime
>> time base to be used for xenolinux.  That support would require
>> additional
>> changes to Linux (eg a Xen aware implementation of /dev/rtc & etc.),
>> and
>> should probably be based on a more flexible and thorough 
>> implementation
>> of
>> non-UTC guest time bases than what this patch provides.  Nevertheless,
>> this patch is functionaly equivalent to what is being done SLES 10's
>> Xen
>> implementation (but with SLES10 being based on testing tree), so I 
>> felt
>> it
>> should be submitted as is, with a more comprehensive approach
>> submitted
>> separately.
>>
>> Signed-off-by: Bruce Rogers < brogers@novell.com>
>>
>> - Bruce
>>
>> >>> On 4/5/2006 at 8:03 AM, in message
>> <268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk >, Keir Fraser
>> <Keir.Fraser@cl.cam.ac.uk> wrote:
>>
>> > On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
>> >
>> >> This patch allows the localtime parameter to be used for
>> >> para-virtualized guests.
>> >> Some paravirtualized guests may need to start with a local time
>> basis
>> >> instead of UTC.
>> >> This patch provides for that need.  Please review and apply.
>> >
>> > I've just checked in a patch to provide a clean wallclock update
>> > interface from common Xen code. Please re-send based on that patch.
>> > Your dom0_op implementation should modify d->time_offset_seconds
>> > directly and then call update_domain_wallclock_time(d).
>> >
>> > Apart from that, the time_offset_seconds field in dom0_op.h should 
>> be
>>
>> > type int32_t (we don't use s32 in public headers).
>> >
>> >   -- Keir
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>>  http://lists.xensource.com/xen-devel
>>
>>
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Keir Fraser]

On 21 Jun 2006, at 16:49, Keir Fraser wrote:

>>  - this is a different mechanism than the one used to set time 
>> offsets for fully virtualized guests. At the lowest levels, this is 
>> probably difficult to avoid.  Higher up, though, it would be nice if 
>> this type of capability didn't look/act and be controlled 
>> differently.  The differences between fully and para virtualized 
>> systems should disappear the higher into the control logic you go.  
>> Were you able to give any thought on how to merge the models ?
>
> The 'support' for full-virt guests is *only* a qemu patch right now. 
> No tools integration at all. Integration would have to be in xend, as 
> it is xend which kicks off the qemu-dm process for HVM guests. Setting 
> the 'timeoffset' based on the localtime config option wouldn't be very 
> hard, and would unify that new option across PV and HVM guests. 
> Patches welcome (and moving the logic to work out what the time offset 
> should be from xc.c into xend itself would be nice).

Also, RTC emulation really belongs in Xen anyway, so it'll be possible 
to unify at the dom0_op level at that point.

  -- Keir

Re: [PATCHl] localtime basis for paravirtualized guests

[B Thomas]

[-- Attachment #1.1: Type: text/plain, Size: 1280 bytes --]

On 6/21/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
>
>
> On 21 Jun 2006, at 16:49, Keir Fraser wrote:
>
> >>  - this is a different mechanism than the one used to set time
> >> offsets for fully virtualized guests. At the lowest levels, this is
> >> probably difficult to avoid. Higher up, though, it would be nice if
> >> this type of capability didn't look/act and be controlled
> >> differently. The differences between fully and para virtualized
> >> systems should disappear the higher into the control logic you go.
> >> Were you able to give any thought on how to merge the models ?
> >
> > The 'support' for full-virt guests is *only* a qemu patch right now.
> > No tools integration at all. Integration would have to be in xend, as
> > it is xend which kicks off the qemu-dm process for HVM guests. Setting
> > the 'timeoffset' based on the localtime config option wouldn't be very
> > hard, and would unify that new option across PV and HVM guests.
> > Patches welcome (and moving the logic to work out what the time offset
> > should be from xc.c into xend itself would be nice).
>
> Also, RTC emulation really belongs in Xen anyway, so it'll be possible
> to unify at the dom0_op level at that point.
>
>   -- Keir


Yes; I agree. That would be reasonable.

-b

[-- Attachment #1.2: Type: text/html, Size: 1716 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCHl] localtime basis for paravirtualized guests

[Keir Fraser]

On 21 Jun 2006, at 00:20, Bruce Rogers wrote:

> I should point out however that this by itself does not allow a
> localtime
> time base to be used for xenolinux.  That support would require
> additional
> changes to Linux (eg a Xen aware implementation of /dev/rtc & etc.),
> and
> should probably be based on a more flexible and thorough implementation
> of
> non-UTC guest time bases than what this patch provides.

I'm not sure what you mean here. If Xen adds an offset to wc_sec then 
XenLinux will see a different wallclock time. Right? RTC isn't emulated 
or used by domUs.

  -- Keir

Re: [PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

The way Linux gets its UTC time when it is running from a locatime
time base is that hwclock is called from the init scripts and it reads
/dev/rtc, offsets that value by the local time offset, and resets the
kernel's time via the settimeofday system call.  So if /dev/rtc was
tied straight into the time retrieved from Xen (speaking of the 
DomU case) this all works correctly to reset the kernel's sense
of time to be UTC.  As it stands today, hwclock fails because
neither /dev/rtc nor direct access to the RTC via port I/O is
there for a DomU.

Without the above actions taking place, the kernel is left
using localtime (from Xen) as if it was UTC, and the
localtime derived from that is off.  I've got the rtc.c code
hacked up to make it work but before I proceeded down that
path further, was interested in hearing what others thought
might be the best solution for allowing guests to use Xen as
a time basis, but be more flexible with managing its own time.

- Bruce

>>> On 6/21/2006 at 10:11 AM, in message
<220a261ede8f0089ecc6a7c408cea2b8@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:

> On 21 Jun 2006, at 00:20, Bruce Rogers wrote:
> 
>> I should point out however that this by itself does not allow a
>> localtime
>> time base to be used for xenolinux.  That support would require
>> additional
>> changes to Linux (eg a Xen aware implementation of /dev/rtc &
etc.),
>> and
>> should probably be based on a more flexible and thorough
implementation
>> of
>> non-UTC guest time bases than what this patch provides.
> 
> I'm not sure what you mean here. If Xen adds an offset to wc_sec then

> XenLinux will see a different wallclock time. Right? RTC isn't
emulated 
> or used by domUs.
> 
>   -- Keir

Re: [PATCHl] localtime basis for paravirtualized guests

[Keir Fraser]

I must be missing something. Are you saying we might want to provide a 
domU with a localtime RTC, which it reads, offsets to UTC (because it 
knows its timezone), and then uses to set UTC time in its kernel? How 
is that better than what we do now, which is to simply provide UTC time 
directly to the kernel, which it can then convert to localtime itself 
when that's appropriate?

  -- Keir

On 21 Jun 2006, at 22:23, Bruce Rogers wrote:

> The way Linux gets its UTC time when it is running from a locatime
> time base is that hwclock is called from the init scripts and it reads
> /dev/rtc, offsets that value by the local time offset, and resets the
> kernel's time via the settimeofday system call.  So if /dev/rtc was
> tied straight into the time retrieved from Xen (speaking of the
> DomU case) this all works correctly to reset the kernel's sense
> of time to be UTC.  As it stands today, hwclock fails because
> neither /dev/rtc nor direct access to the RTC via port I/O is
> there for a DomU.
>
> Without the above actions taking place, the kernel is left
> using localtime (from Xen) as if it was UTC, and the
> localtime derived from that is off.  I've got the rtc.c code
> hacked up to make it work but before I proceeded down that
> path further, was interested in hearing what others thought
> might be the best solution for allowing guests to use Xen as
> a time basis, but be more flexible with managing its own time.
>
> - Bruce
>
>>>> On 6/21/2006 at 10:11 AM, in message
> <220a261ede8f0089ecc6a7c408cea2b8@cl.cam.ac.uk>, Keir Fraser
> <Keir.Fraser@cl.cam.ac.uk> wrote:
>
>> On 21 Jun 2006, at 00:20, Bruce Rogers wrote:
>>
>>> I should point out however that this by itself does not allow a
>>> localtime
>>> time base to be used for xenolinux.  That support would require
>>> additional
>>> changes to Linux (eg a Xen aware implementation of /dev/rtc &
> etc.),
>>> and
>>> should probably be based on a more flexible and thorough
> implementation
>>> of
>>> non-UTC guest time bases than what this patch provides.
>>
>> I'm not sure what you mean here. If Xen adds an offset to wc_sec then
>
>> XenLinux will see a different wallclock time. Right? RTC isn't
> emulated
>> or used by domUs.
>>
>>   -- Keir

Re: [PATCHl] localtime basis for paravirtualized guests

[Bruce Rogers]

No you aren't missing anything ;-)  Simply providing UTC to a linux DomU
is
by far the simplest way to go, as you point out.  But given that my
patch
creates the option of launching a domain with localtime as its time
base
(which P.V. NetWare needs), I'm just pointing out what we found to be
the
additional infrastructure that would be needed to get linux to work
correctly
_if_ you wanted to have it correctly work with a localtime time base.

Our SLES 10 YaST module defaults to UTC when creating linux guests,
but
the option to use localtime is also there, while the additional
infrastructure
mentioned (/dev/rtc support, etc) is, unfortunately, not.  So we are
for
the moment documenting that linux guests should have their virtual
hardware clocks set to UTC, which is what most everyone would
naturally
do.

My patch solves NetWare's needs just fine, but is insufficent for
linux,
and I think a much more universal solution than what my patch
implements
is needed longer term.

- Bruce


>>> On 6/21/2006 at 3:45 PM, in message
<9d0d38d120a8176845142085d3822671@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:

> I must be missing something. Are you saying we might want to provide
a 
> domU with a localtime RTC, which it reads, offsets to UTC (because it

> knows its timezone), and then uses to set UTC time in its kernel? How

> is that better than what we do now, which is to simply provide UTC
time 
> directly to the kernel, which it can then convert to localtime itself

> when that's appropriate?
> 
>   -- Keir
> 
> On 21 Jun 2006, at 22:23, Bruce Rogers wrote:
> 
>> The way Linux gets its UTC time when it is running from a locatime
>> time base is that hwclock is called from the init scripts and it
reads
>> /dev/rtc, offsets that value by the local time offset, and resets
the
>> kernel's time via the settimeofday system call.  So if /dev/rtc was
>> tied straight into the time retrieved from Xen (speaking of the
>> DomU case) this all works correctly to reset the kernel's sense
>> of time to be UTC.  As it stands today, hwclock fails because
>> neither /dev/rtc nor direct access to the RTC via port I/O is
>> there for a DomU.
>>
>> Without the above actions taking place, the kernel is left
>> using localtime (from Xen) as if it was UTC, and the
>> localtime derived from that is off.  I've got the rtc.c code
>> hacked up to make it work but before I proceeded down that
>> path further, was interested in hearing what others thought
>> might be the best solution for allowing guests to use Xen as
>> a time basis, but be more flexible with managing its own time.
>>
>> - Bruce
>>
>>>>> On 6/21/2006 at 10:11 AM, in message
>> <220a261ede8f0089ecc6a7c408cea2b8@cl.cam.ac.uk>, Keir Fraser
>> <Keir.Fraser@cl.cam.ac.uk> wrote:
>>
>>> On 21 Jun 2006, at 00:20, Bruce Rogers wrote:
>>>
>>>> I should point out however that this by itself does not allow a
>>>> localtime
>>>> time base to be used for xenolinux.  That support would require
>>>> additional
>>>> changes to Linux (eg a Xen aware implementation of /dev/rtc &
>> etc.),
>>>> and
>>>> should probably be based on a more flexible and thorough
>> implementation
>>>> of
>>>> non-UTC guest time bases than what this patch provides.
>>>
>>> I'm not sure what you mean here. If Xen adds an offset to wc_sec
then
>>
>>> XenLinux will see a different wallclock time. Right? RTC isn't
>> emulated
>>> or used by domUs.
>>>
>>>   -- Keir

wallclock time for paravirtualized guests

[Bruce Rogers]

[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]

The paravirtualized guests are offered wallclock time referenced to UTC
only, while fully virtualized guests are given the option via the config
file (localtime parameter) of starting with UTC time or local time.
What would it take to optionally provide localtime to the
paravirtualized guests as well?
For a guest that launches assuming localtime as its time basis, then
later deriving UTC from it based on configuration files, this is
problematic, requiring some convolutions to how it handles time as it
boots.
Is there some place where we can insert a localtime offset into the
start-of-day structure, or perhaps change the sharedinfo wallclock time
to be either localtime or utc, depending on a localtime parameter in the
config file, similar to what is done for fully virtualized guests?
 
- Bruce Rogers

[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 1104 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

wallclock time for paravirtualized guests

[Bruce Rogers]

The paravirtualized guests are offered wallclock time referenced to UTC only, while fully virtualized guests are given the option via the config file (localtime parameter) of starting with UTC time or local time.
What would it take to optionally provide localtime to the paravirtualized guests as well?
For a guest that launches assuming localtime as its time basis, then later deriving UTC from it based on configuration files, this is problematic, requiring some convolutions to how it handles time as it boots.
Is there some place where we can insert a localtime offset into the start-of-day structure, or perhaps change the sharedinfo wallclock time to be either localtime or utc, depending on a localtime parameter in the config file, similar to what is done for fully virtualized guests?
 
- Bruce Rogers