Reyk Floeter [r...@openbsd.org] wrote:
>
> Yes, KVM???s stable bit is not a reliable indication as it is seems to depend
> on the capabilities of the KVM version and not the actual availability of the
> feature on the particular hardware. How annoying.
>
> As mentioned before: I???d like to disable pvclock for now and I can do that
> in the morning CET if nobody beats me to it.
>
> I have an idea how to deal with old platforms afterwards but this needs some
> more tests and thoughts.
>
Perhaps the solution is as "simple" as checking the status of the bit
after the presence of the bit is established ?
Index: pvclock.c
===================================================================
RCS file: /cvs/src/sys/dev/pv/pvclock.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 pvclock.c
--- pvclock.c 24 Nov 2018 13:12:29 -0000 1.2
+++ pvclock.c 4 Dec 2018 00:53:56 -0000
@@ -127,8 +127,10 @@ pvclock_match(struct device *parent, voi
void
pvclock_attach(struct device *parent, struct device *self, void *aux)
{
- struct pvclock_softc *sc = (struct pvclock_softc *)self;
- paddr_t pa;
+ struct pvclock_softc *sc = (struct pvclock_softc *)self;
+ struct pvclock_time_info *ti;
+ paddr_t pa;
+ uint8_t flags;
if ((sc->sc_time = km_alloc(PAGE_SIZE,
&kv_any, &kp_zero, &kd_nowait)) == NULL) {
@@ -151,6 +153,13 @@ pvclock_attach(struct device *parent, st
/* Better than HPET but below TSC */
sc->sc_tc->tc_quality = 1500;
+
+ ti = sc->sc_time;
+ flags = ti->ti_flags;
+ if ((flags & PVCLOCK_FLAG_TSC_STABLE) == 0) {
+ printf(": unstable timestamp counter\n");
+ return;
+ }
tc_init(sc->sc_tc);
