On Mon, Nov 14, 2011 at 09:48:45AM +0000, Jan Beulich wrote:
> >>> On 11.11.11 at 19:39, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >>> wrote:
> > On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:
> >> Hi all,
> >>
> >> Already posted this over in xen-users and Konrad confirms it as a
> >> bug and suggested to repost
> >> it over here!
> >
> > Laszlo, Paolo, Jan, you guys haven't seen domething like this? It looks
> > like a hypervisor issue where the wallclock time is not really dispursed
> > in the shared_info.
>
> Hypervisor? Upstream up to and including 3.1 just doesn't issue the
> necessary hypercalls. This was fixed only recently through patches
> from Jeremy. We had a different issue in that respect in the forward
> ported Linux trees, but that got fixed a couple of months ago, too.
Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.
The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.
If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
>
> This not working in Jeremy's 2.6.32 tree is odd though, but I'm not
> certain which branches the necessary code would on.
>
> >>
> >> Issue is that changing the time in dom0 doesn't take effect on the
> >> VMs until a reboot of dom0.
> >> The testing example below illustrates what I mean....
> >>
> >> Synopsis of testing:
> >>
> >> Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
> >> Booted a VM (using xl as xm seems to be labouring under the
> >> impression that blockdev is missing - it isn't)
> >> The login prompt displays the time as 17:17, which is the expected
> >> behaviour.
> >> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
> >> Check that date and hwclock match - they do.
> >> Destroy the VM and recreate.
> >> The login prompt displays the time as 17:22. Unexpected!
> >>
> >>
> >> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and
> >> applied xen-settime patches
> >> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch,
> >> they wouldn't apply.
> >> Xen: 4.1.1/4.1.2
> >> Distribution: Gentoo
> >>
> >> It still doesn't work.
> >>
> >> I've tested that the issue also exists in Debian Squeeze (with
> >> linux-image-3.0.0 from testing as 2.6.32-5 is broken
> >> on my hardware).
> >> --
> >>
> >> *Niall Fleming BSc. (Hons)*
> >> Systems Administrator
> >> Webanywhere Limited
> >>
> >> Phone: 0800 862 0131 Ext: 203
> >> Web: http://www.webanywhere.co.uk
> >>
> >> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> >> Registered in England with company number 4881346
> >
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home