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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"