bhyve should expose invariant TSC
When bhyve was ported to illumos, the logic for exposing the invariant TSC property was skipped. A TSC is considered invariant when its frequency will not be effected by changes in CPU state such as P-state transitions. Presently, illumos has detection logic in the SpeedStep and PowerNow drivers to preclude their use if invariant TSC functionality is not present. Because of that, and because illumos bhyve does not support host suspend/resume, it should be a reasonable assumption that the TSC will run at its measured frequency without interruption. Any skew between CPU TSC values is measure during boot and available to bhyve to configure VMX/SVM TSC offsets so there is no perceived difference in the guest as a vCPU migrates between physical CPUs.
Updated by Patrick Mooney over 1 year ago
Despite the fact that illumos disables power features that should make it safe to expose an invariant TSC to guests on physical CPUs which lack the feature, that was decided to be too excessive for this change. It was updated to only expose that feature if the physical CPU possess it. There was an added optional override variable which could be used to get the full unconditional exposition if required for development purposes.
With all that said, this was tested on Intel (Ivy Bridge) and AMD (Rome) hardware to check guest behavior. Both CPUs support invariant TSC, and so they should pass it on to the guest. On Linux, that can be checked by looking for
constant_tsc in the
/proc/cpuinfo flags list. It was indeed listed there on both systems.
Updated by Electric Monk over 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 9250eb132f1fc3950c838b7a5746f1bcdac7eba1 Author: Patrick Mooney <email@example.com> Date: 2021-02-09T04:09:15.000Z 13375 bhyve should expose invariant TSC 13381 support TSC offsets on AMD bhyve 13382 consolidate MSR emulation in bhyve Reviewed by: Andy Fiddaman <firstname.lastname@example.org> Reviewed by: Jason King <email@example.com> Reviewed by: Mike Zeller <firstname.lastname@example.org> Reviewed by: Robert Mustacchi <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>