Skip TSC calibration if exact value known

[cperciva]

Summary

It's possible that the "early" TSC calibration gave us a value which
is known to be exact; in that case, skip the later re-calibration.

Test Plan

Darius has a VMWARE system and has offered to test this.

This patch should result in little or no change to kern.timecounter.tc.TSC but a second of DELAY being shaved off from the boot time.

[cperciva]

Darius (Daniel O'Connor) has tested and confirms that this operates as expected under VMWare -- the TSC-low timecounter is set up correctly, but the 1 second of calibration time is gone.

[markj]

sys/x86/x86/tsc.c

62

This can be qualified with static.

271

I think it'd be a bit neater to set this flag in tsc_freq_vmware().

[cperciva]

Adjust per markj's comments

[cperciva]

Thanks! Does it look good now?

[markj]

In D33695#761743, @cperciva wrote:

Thanks! Does it look good now?

Looks reasonable to me, thanks. We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

[cperciva]

In D33695#761746, @markj wrote:

We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

I wondered about that -- does 0x15 say what the frequency *is* or what the frequency *should be*? (Thinking about overclocking etc here).

I'm already planning on splitting the vmware bit so that the cpuid value from there can be used with other hypervisors -- KVM for one publishes that leaf. (Which means it's available in EC2.)

[markj]

In D33695#762390, @cperciva wrote:

In D33695#761746, @markj wrote:

We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

I wondered about that -- does 0x15 say what the frequency *is* or what the frequency *should be*? (Thinking about overclocking etc here).

It provides the ratio of the TSC frequency and the "core crystal clock" frequency, as well as the nominal core crystal clock frequency. CPUID leaf 0x16, which provides the "processor base frequency," is described in the SDM with the caveat that, "Data is returned from this interface in accordance with the processor's specification and does not reflect actual values." There's no similar language in the description of leaf 0x15, so that and some reading of the DPDK and Linux code makes me think that 0x15 can be trusted to give an accurate value.