want mechanism to enable paravirt clock safely #8001
Description
Propolis offers a Hyper-V-compatible paravirtualized clock enlightenment. We'd like to enable this for guests that know how to use it so that they don't conclude that the TSC is unreliable and fall back to emulated hardware timers, which are much more expensive to access.
While Propolis tries to follow the Hyper-V TLFS, it and bhyve are obviously not exactly Hyper-V, and we've seen in practice that some guests (e.g. some flavors of FreeBSD, illumos distributions) panic when Hyper-V emulation is enabled. (This is not a problem with the TSC enlightenment as such, as far as I'm aware; the issue is more that some guests read the hypervisor CPUID leaves, see a Hyper-V identifier, and assume that the hypervisor has other properties that Propolis/bhyve happen not to have.)
We need a way to enable this kind of virtualization feature broadly while giving users the opportunity to opt specific instances out if it happens to break them.
Related work:
- want paravirtualized clock enlightenment propolis#328 - Propolis ticket tracking the paravirt clock enlightenment work
- sled-agent: enable Hyper-V TSC enlightenment for new VMs #7783 - initial attempt to enable the enlightment globally
- sled-agent: revert Hyper-V enablement #7868 - rollback of 7783
- RFD 561 discusses possible approaches that would allow users to configure virtualization features as desired here
Next steps are to close out on a design in RFD 561 and then implement whatever design is chosen.