On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
> Ian Lepore writes:
> > 
> > Beyond that, I'm not sure what else to try.  It might be necessary to
> > get some bhyve developers involved (I know almost nothing about it).
> NTPD behaves more normally on uniprocessor VMs.
> A FreeBSD bhyve-guest running on a freebsd host will select a
> different timecounter depending on whether it is a multiprocessor or a
> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
> timecounter in a uniprocessor.  NTP functions there as expected.
> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
> dummy(-1000000)
> kern.timecounter.hardware: TSC-low
> The very same VM, when given two total CPUs, selected HPET (if I
> recall) and the timekeeping with NTPD was unreliable, with many
> step-resets to the clock.

Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
looks right.  I wonder if this is just a simple roundoff error in
converting between 10.0MHz and SBT units?  If so, that could be wished
away easily by using a power-of-2 frequency for the virtual HPET.  I
wonder if the attached patch is all that's needed?

-- Ian
Index: sys/amd64/vmm/io/vhpet.c
--- sys/amd64/vmm/io/vhpet.c	(revision 324176)
+++ sys/amd64/vmm/io/vhpet.c	(working copy)
@@ -51,7 +51,7 @@ __FBSDID("$FreeBSD$");
 static MALLOC_DEFINE(M_VHPET, "vhpet", "bhyve virtual hpet");
-#define	HPET_FREQ	10000000		/* 10.0 Mhz */
+#define	HPET_FREQ	16777216		/* 16.7 (2^24) Mhz */
 #define	FS_PER_S	1000000000000000ul
 /* Timer N Configuration and Capabilities Register */
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to