Re: [Xen-users] [Xen-devel] Xen domU Timekeeping

[Qrux <qrux.qed@xxxxxxxxx>]

Thanks, Ian and Konrad, for your responses.  More questions inline...

On Feb 14, 2012, at 8:19 AM, Ian Campbell wrote:

>>>     * Is there a way to keep good time (i.e., bare-metal accuracy) on domU?
>> 
>> It does that now. It uses the same clock as the hypervisor does so there
>> is no "lost ticks" or such.

Awesome.

Are pvops kernels (dom0 and domU) using tickless timekeeping when configured 
with NO_HZ?  If not, what is it doing?  If so, which clocksource is it using?  
TSC?  HPET?  What are the proper options to set in the kernel?

If one doesn't use NO_HZ, are pvops kernels counting ticks to keep time?  If 
so, which clocksource does that use?  PIT?  And, what are the proper options 
for that?

        Q: Which configuration is "preferred" in the interest of good 
timekeeping?

Obviously, a tick-counting kernel will generate far more interrupts.  OTOH, 
one-shot tickless timekeeping has higher latencies, AFAIK.  So, if there *is* a 
preferred configuration for good timekeeping...

        Q: Does "good timekeeping" trade-off other benefits?

> A pvops kernel has no concept of dependent_wallclock and is effectively
> always in independent_wallclock mode. Jeremy made this call IIRC because
> it matches how native works which reduces the special casing needed for
> VMs.
> 
> This does however mean that you need to run NTP in a guest which runs a
> pvops kernel.

I'm thoroughly baffled.  Konrad basically said that domUs uses the same time as 
the hypervisor.  That sort of implies dependent_wallclock (at least in 
operation, if not explicitly as a kernel feature).  But, then, Ian said that we 
need to run NTP in a pvops guest.  Which sort of implies independent_wallclock.

        Q: Which is it?

====
I think I get the picture; please correct me if this is a misunderstanding:

Only dom0 has access to the RTC (via hwclock or the ioctl interface).  But, 
domU doesn't (which I verified, at least with hwclock--it complained about no 
way to access any hardware clock).  Since domU doesn't have a working hwclock, 
someone has to set "wall time" (the way that dom0 can with hwclock, or via the 
kernel during boot).

So, we use NTP on domU to retrieve a time.  But, I assume that *any* time 
source can be used for this purpose, even old port-13-daytime.  Basically, we 
just need something as roughly accurate as RTC to give a "reference start time" 
to the kernel/software/system clock--which I believe are all the same, 
according to the usage in time(7) and rtc(4).

In addition, I believe NTP uses adjtimex (on Linux) to discipline the kernel 
clock--but  not RTC (see usage).  Which would imply that it's safe to run on 
domU (though, how accurate it can be...is unclear).
====

*Whew*

So, if that *is* the picture...we can move on to the meat of it!

If a pvops domU cannot see the RTC, it has no fracking idea what time it is 
(calendar/wall time).  It only knows what *relative* time it is, w.r.t. when it 
was created.  Now, on most bare-metal setups, NTP comes into the process way 
late.  Like, rc3.d-late.  Which means if we're doing disk-mounts in rcS.d, fsck 
will have no idea what time it is.

Are there bad interactions if fsck doesn't have any clue what time it is?  Does 
this also mean that NTP should get started earlier?  And, if so, does that 
imply networking would need to be moved way up in rcS.d?  I assume there *must* 
be guidelines about what *needs* to go into pvops domU /etc/{rc,init}.d/, and 
suggested orderings.

        Q: What is the correct sequence of events on pvops domU boot?

And, finally, for my specific situation, does this help explain why my ext4 
domU (which uses an LVM volume formatted with ext4 on dom0) won't reboot, but a 
ext3 one will?  Is ext4 pickier about times during the loading of its driver?

        Q


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