sys/x86/x86: Handle when MPERF/APERF MSRs aren't writable

[ziaee]

Summary

"For performance and/or correct reasons some hypervisors allow
MPERF/APERF MSRs to be read but not written to. This change
modifies the handling of these MSRs to not rely on writes."

This patch is part of Google Cloud Engine C4-lssd turnup.

Proxied on behalf of Matt Delco <[e-mail]>, note that
I (ziaee) do not understand what is going on here whatsoever.

Sponsored by: Google

[jrtc27]

sys/x86/x86/cpu_machdep.c

463

This is to avoid division by zero, I assume, but that is a separate issue that could occur with the existing code in the same situation, i.e. if DELAY(1000) isn't enough to make them tick up (or they exactly wrap around). If you want to make that change it should be a separate commit, though start_TSC is supposed to be catching this possibility, no? (Not sure exactly what the conditions are here for when each snippet runs...)

sys/x86/x86/tsc.c

446

Hm, being read-only is a bit different. The "test whether they really work" is to make sure that they tick up. I think you just want to add the read-only part as a separate sentence afterwards?

452–454

Rogue space before the closing parenthesis, and no need to add the braces

[obiwac]

overall looks good

sys/x86/x86/tsc.c

436

presumably?

[olce]

Looks good modulo jrtc27's suggestions.

sys/x86/x86/cpu_machdep.c

463

It's true the same possibility exists with the original code. Given what is done is start_TSC(), that can appear redundant, but really we should prepare for weird emulator behaviors, and this test costs basically nothing, so IMO it should be done (whether in a separate commit or here in passing).

sys/x86/x86/tsc.c

435–436

Typo here (existing patch should not compile).