|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up tim
To: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Subject: |
Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU |
From: |
Tim Deegan <Tim.Deegan@xxxxxxxxxx> |
Date: |
Fri, 15 Oct 2010 15:58:18 +0100 |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Shunli Yi <syi@xxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Saipu Liu <saliu@xxxxxxxxxxxx>, Hang Du <hdu@xxxxxxxxxxxx> |
Delivery-date: |
Fri, 15 Oct 2010 08:00:05 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<68d8910d-1630-482f-aab3-9e3ea068fec1@default> |
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> |
References: |
<9C56B6AEEB2D60488B29B880DF7E53BE03C1B2C6B6@xxxxxxxxxxxxxxxxxxxxx> <4CB4672E020000780001C752@xxxxxxxxxxxxxxxxxx> <0b6cc1b3-f838-482e-89dc-6f19cc8c47cc@default> <20101013161657.GJ4007@xxxxxxxxxxxxxxxxxxxxxxx> <68d8910d-1630-482f-aab3-9e3ea068fec1@default> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
At 15:46 +0100 on 15 Oct (1287157606), Dan Magenheimer wrote:
> Agreed that this is a better solution to a very important problem.
> I'm just trying to determine if it helps solve another time-related
> real world problem.
Yep. AFAICS it doesn't really affect that at all. :|
> > - all the user really needs is a generation counter to know that the
> > clock correction values are stale, and the kernel can provide that
> > alongside the stime.
>
> Agreed that a generation counter solves this. BUT...
>
> (1) afaik there is no generation counter in any time-related
> kernel API; and
OK, but one could be added wherever the stime is exposed. This line of
reasoning runs into the earlier discussions about PV time protocols fopr
userspace (inluding process migration &c), and I've nothing useful to
add to that now. :)
> (2) afaict this generation counter would need to be "pushed"
> from the dom0 kernel so would either (a) require domU kernels
> to read from xenstore, or (b) require some kind of privileged
> hypercall from dom0 to the hypervisor telling the hypervisor
> to change the generation counter (and scaling values?) for all
> domUs.
I was under the impression that the only time you'd really need to
invalidate the xenstore values was on live migration, which the domU
kernel can certainly know about. One reason they use xenstore is that
the correction numbers are quite stable and don't need to be polled
every time.
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|