[ Charset UTF-8 unsupported, converting... ]
> 22.10.2017 01:15, Ian Lepore ?????:
> > 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?
> I've tried the patch (at bhyve guest) and nothing has changed. Should
> the patched system be tested at bhyve guest or bhyve host?

I believe the suggested patch would have to be made to the bhyve
host.  Also on the host and guest what are the values of
        sysctl kern.timecounter.tc.HPET
        sysctl kern.timecounter.tc.i8254

Getting good ntpd behavior in a VM guest of any kind is sometimes a
non trivial thing to do.

Rod Grimes                                                 rgri...@freebsd.org
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to