Re: [PATCH] Implement timekeeping for rumprun/hw (x86)

  • From: Antti Kantee <pooka@xxxxxx>
  • To: rumpkernel-users@xxxxxxxxxxxxx
  • Date: Sat, 04 Jul 2015 11:30:02 +0000

On 03/07/15 15:57, Martin Lucina wrote:

On Wednesday, 01.07.2015 at 14:24, Antti Kantee wrote:
I don't know what precisely to do, but it would be good to make sure
the user sees the error, yet does not have to go edit code if they
want to run regardless. Maybe we need some sort of "make error a
warning" flag to rumprun?

Nothing to do with rumprun I think, the platform bootstrap can just print a
suitable warning if the hardware does not do invariant TSC.

You missed the "make *sure* the user sees the error" part. How else are you going to do that except by printing the warning and then refusing to boot by default? If you refuse to boot by default, how else are going let the user to decide to force boot anyway except with an override switch in rumprun? (probably some other ways, but that was the most obvious way for my imagination)

I don't want to ship a system with weird bugs where the blame is on the user for not studying the full boot output on every system they deploy on.

However, I am concerned about the case where the host has SMP. Is
tsc always sufficiently virtualized?

To be honest, I don't know. See the references at the end of this email.
The answer is "probably, yes" but we'll have to wait and see what happens
in reality when people start using it.

In the interest of getting this tested by users ASAP, and given that I've
addressed all the major points, I'm going to merge this now and continue
working on it in-tree. I'm doing that with the full history of changes
since I started working on it, since I'd like to keep that as a record of
the thought process that went into it.

Bug shakedowns are one thing, but it would be nice to see the author extrude more confidence than "probably" for if the introduced technique is not fundamentally broken... At least add a check-and-panic for tsc not going backwards if you're not sure it never will. Otherwise people may run into utterly weird failure modes in the order of "some funny stuff happens sometimes in some environment".

The clock seems to run at about 2/5 speed under no-kvm QEMU (i.e. sleep 2 takes ~5 seconds). Is that expected?

Other related posts: