> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Sent: 2010年10月13日 23:56
> To: Jan Beulich; Du, Hang; Keir Fraser; Jeremy Fitzhardinge
> Cc: Liu, Saipu; Yi, Shunli; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up
> time from dom0 to domU
>
> (bringing the topic up to a more theoretical level and including Keir and
> Jeremy)
>
> I wonder if the "bug" here is that "dependent wall clock" is an incredibly
> poor
> replacement for NTP (or a Windows Time Server) and a hack and really shouldn't
> even exist? I suppose one could argue that it makes some sense in a XCP
> environment, and maybe in a server environment where a single physical server
> is extremely isolated, but does it ever make sense in a real world server
> environment?
>
[Shunli] We encounter the time-syncing issue when deploy enterprise
applications.
We suppose the "dependent wall clock" feature is for some enterprise
environment (or products) which have uniform administrator and manager tool.
So, they can maintain the time on Dom0 only, and Xen would maintain the time in
DomainUs.
Why we think this defect should be fixed?
1. We implemented a forward time syncing from Dom0 to DomU, also the backward
time syncing should be supported.
2. Currently, backward time setting in Dom0 would cause some DomU applications
hang (when set "independent_wallclock=0").
For example : rpm
3. We don't think the backward time setting is risk for DomUs, this only
impacts the DomUs who set "independent_wallclock=0", and the administrator
should always know what they are doing.
> In other words, I'm arguing that the correct "fix" here is:
> Don't use dependent wallclock.
[Shunli] Of cause, we can, don't use the dependent wallclock.
But, we still want to do something for those peoples who want the "dependent
wallclock".
It's easy to fix, and we didn't hear known risks about changing time backward
in DomU.
>
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> > Sent: Wednesday, October 13, 2010 6:38 AM
> > To: Hang Du
> > Cc: Saipu Liu; Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when
> > sync up time from dom0 to domU
> >
> > >>> On 13.10.10 at 05:24, "Du, Hang" <hdu@xxxxxxxxxxxx> wrote:
> > > Sorry for my brief description in previous mail and missing
> > > is_initial_xendomain check. The kernel I submit this patch is
> > > linux-2.6.18-xen-3.4.2, I submit the patch again with in_initial-
> > xendomain
> > > check.
> >
> > Actually, I didn't expect you to blindly insert that check, but rather
> > either explain why only DomU-s need the changed behavior (as your
> > original description suggested), or refine the description of the
> > problem you're trying to solve.
> >
> > > In this patch, we support the backward time changing sync to all
> > domUs which
> > > configured to use "dependent wall clock".
> > > Currently, without the backward time syncing, when we change the
> > > time backward in Dom0, the time in DomU would be froze.
> > > And this cause some commands hang and don't executed until the time
> > catch up
> > > with the domU time.
> > > For example:
> > > "rpm -q kernel-xen"
> > > "sleep 1"
> > > Monotonic time should be reset when sync up time from dom0 to domU
> > > to support domU backward time syncing.
> >
> > I can see your point, however ...
> >
> > > diff -urN a/arch/i386/kernel/time-xen.c b/arch/i386/kernel/time-
> > xen.c
> > >
> > > --- a/arch/i386/kernel/time-xen.c 2010-10-11 10:41:06.000000000
> > +0800
> > > +++ b/arch/i386/kernel/time-xen.c 2010-10-11 10:43:32.000000000
> > +0800
> > > @@ -715,6 +715,8 @@
> > > }
> > >
> > > if (shadow_tv_version != HYPERVISOR_shared_info->wc_version) {
> > > + if (!is_initial_xendomain() && !independent_wallclock)
> > > + monotonic_reset();
> > > update_wallclock();
> >
> > ... you definitely need to call monotonic_reset() *after* the
> > update_wallclock() (or else another vCPU, preempted in
> > do_gettimeofday() between the end of the xtime read loop and the
> > acquiring of the monotonic lock, would be able to overwrite
> > monotonic.tv with values obtained before the wall clock update -
> > similar to the secondary problem addressed by c/s 1021).
> >
> > Further, blindly running a reset here doesn't seem nice in the
> > (general) case of the time getting updated forwards.
> >
> > > schedule_clock_was_set_work = 1;
> > > }
> >
> > You'll also want to address Dan's concerns, and you will want to get
> > your patch formatted so that it would actually apply (read:
> > no tab -> space conversion) if you expect it to be committed by Keir
> > at some point.
> >
> > Jan
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
>
> To report this as spam, please forward to spam@xxxxxxxxxxxxx Thank you.
Protected by Websense Hosted Email Security -- www.websense.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home