Do I really need to support PIT on a 64 bit kernel?

[indigo256]

This might be a stupid question, but in the real world, are there x86-64 CPUs that don't support HPET? I can't find any documentation claiming that it's a standard for x64 CPUs, but I'd rather not constantly have to develop/test two timers (HPET and PIT) at once if I don't have to.

Yes, I know the wiki says to check the MADT tables. I already parse them no problem, and the 4 computers I've tested on have HPET. I'm just getting kind of impatient and want to boot my other cores, but architecturally it seems better to do those one shot timings with the proper (best) timer.

[Gigasoft]

CPUs do not need to do anything special to support HPET. But any computer that was made in 2003 won't have a HPET, and it is also possible that the user has disabled the HPET in the BIOS.

[Korona]

Some general notes on timers on x86: by far the best timer is the TSC, if invariant TSC is available. Always use the TSC for time keeping in this case: it is generally faster to read from the CPU (two to three orders of magnitude faster than the HPET/PIT/APIC timer) and can be read from user space (makes a huge difference for programs that read the time frequently, e.g., instrumentation-based profiling). If TSC deadline mode is available, use the TSC for interrupts, too. Otherwise, use the local APIC timer in one-shot mode for interrupts.

Use HPET, PIT or the ACPI timer to calibrate the TSC and/or local APIC.

In case invariant TSC is not available, things become more complicated. I would suggest to set the local APIC timer to a fixed interval and to use that for scheduling and for time keeping (since the local APIC is also very fast to read). HPET can then be used to provide more precise interrupts (at time frames that are considerably shorter than the period that you set for the local APIC).

[indigo256]

Somehow I had no idea that consistent TSC existed. Regardless, it sounds like I should prepare for any scenarios where any combination of clocks exist... but I'm likely overestimating how hard the implementation will be. I guess I don't even really need to implement how I'll use the clocks just for booting multiple cores, as I can just have simple one-shot primitives set up for multicore booting.

Just curious, with consistent TSC, when I boot more cores, will those cores have the same value in their own TSC registers?

Also, in your experience, how accurate do the delays need to be for SMP booting? Do I need to worry about the overhead of a few calls in C while delaying?
(Not sure if this is obvious, but I'm kind of running off the example here. https://wiki.osdev.org/SMP#Startup_Sequence)

[Octocontrabass]

Also, in your experience, how accurate do the delays need to be for SMP booting? Do I need to worry about the overhead of a few calls in C while delaying?

It's fine if the delays are too long, but if the delays are too short, the APs may not start.

You can minimize the impact of the delays on startup time by starting multiple APs in parallel. The example code on the wiki won't work if you do this.

[indigo256]

It's fine if the delays are too long, but if the delays are too short, the APs may not start.

That's really good to know, otherwise I would have totally over-engineered booting the other APs by worrying about timers taking too long.